Proxy EOF detection.

Issue NXCM-4864 revealed that pull request
https://github.com/sonatype/nexus/pull/697
is insufficient to handle case when proxy remote peer
drops connection unexpectedly.

NXCM-4864 reveals what exact exception is thrown by HC4
when "remote peer" drops connection unexpectedly. Inspecting
the exception also reveals it is not an `java.io.EOFException`
descendant, but descends directly from `java.io.IOException`.
Hence, changes in pull request
https://github.com/sonatype/nexus/pull/697
(that kicks in on EOFException) will never kick in (and
this case will be handled as "generic IO problem" and will
auto block remote peer too).

So, we introduced a "wrapper" around the HC4 stream, to
have it "translate" HC4 specific exception
into one that is recognised (and handled) by Nexus Core.
Moreover, as it is highly likely that other transports will
use other exceptions (descending or not from EOFException),
using this technique we could always ensure that this case is
properly handled by Nexus Core.

Here, newly introduced Hc4InputStream is meant to translate
the `org.apache.http.ConnectionClosedException` thrown by
`org.apache.http.impl.io.ContentLengthInputStream` read methods.
Merge remote-tracking branch 'origin/master' into proxy-eof

Conflicts:
	nexus/nexus-proxy/src/main/java/org/sonatype/nexus/proxy/storage/remote/httpclient/HttpClientRemoteStorage.java
Cleanup, move into place.
Added UT.

Also, fetch did not propagate EOF exception.
Keep original comment in code.

To have trail why we do not abort in close method
Reformat
Commnet
NEXUX-5542: Reformat, no code change.
NEXUS-5542: Fixing cascade operations.

For now, to have same behavior as with NEXUS-5249,
if a member reports IOEx during cascading operation
the whole task will finish (will continue processing
next members) but method invocation, and hence the
task will fail.
NEXUS-5542: IT for NEXUS-5249 extended for this case too
Workaround to automatically share method interceptors via explicitly bound module sub-types while the Sisu feature to do this properly is implemented
minor tidy and update docs.  drop example
clearify docs
Use sisu-mailer 1.7.1-SNAPSHOT (that uses java mail 1.4.7)

Signed-off-by: Alin Dreghiciu <adreghiciu@gmail.com>
Use sisu mailer 1.7.1

Signed-off-by: Alin Dreghiciu <adreghiciu@gmail.com>
nexus oss 2.4.0-03

Signed-off-by: Sonatype Release Machine <release@sonatype.com>
NEXUS-2450: Maven1 reposes will be asked for EJBs

Nexus doing the "conversion" from M2 to M1 path does not have
all the knowledge about requested artifact, like it's packaging
(it's just been asked for). This change adds a small "twist" to
Nexus layout converting shadows, and the "ejbs" folder will be asked
too before giving up a request. While methods now
return List of paths (instead of just one path as before), nothing
changes and almost every method except the doRetrieveItem will
make use only of the first element of the returned list, yielding
in no change. The doRetrieveItem method will use "extra" paths,
and will iterate of the list of paths trying to get response,
ultimately failing with INFex.
Back to 2.4-SNAPSHOT version
UI: Update URL in local data when proxy repo is saved
[NXCM-5056] Guard getter for response header, some responses do not have this