NEXUS-5612: File listing should fail in case of IO problem

Currently DefaultFSPeer was hiding the null returned
from File.listFiles. According to javadocs, it returns null
in two cases, a) when the File instance does not denote
a directory, or b) in case of IO error.

As case a) is checked few lines above (if check failed,
we would not get here), the null return value should
be treated as IO Error.

By throwing a generic LocalStorageExcetion, we
make this case to be treated as error.
Merge remote-tracking branch 'origin/master' into file-list-io-error
Merge remote-tracking branch 'origin/master' into file-list-io-error
Merge remote-tracking branch 'origin/master' into file-list-io-error
NEXUS-5612: Testing interaction with WalkerProcessor and FSPeer

Especially the case when FSPeer#listItems method throws
LocalStorageException.

The Walk must be stopped, after this, no processor
should have onCollectionExit invoked.

This UT actually simulates the case when due to
too many open files, FSPeer made Walker think
that collection is empty, while it was not.

DefaultFSPeer is already fixed in prev commit,
this UT only ensures that Walker, Context and
Processors behave correctly in this case.
NEXUS-5612: Remove UT since tag

Remnant from copied skeleton UT.
NXCM-5188: NPE fix

In the issue attached log, it's clearly visible that validation
did reject the item (policy=Strict but no hashes were present).
Later, an NPE is thrown, as the cleanup method is not protected
from this case.

In all other case it would work as contentValid would be
TRUE for all of those. This is the only branch in logic
where it is FALSE, and the remoteHash is null too.

In other words, cleanup is needed when content is
invalid, but hashes arrived into cache.
NXCM-5188: Added checksum relax possibility and using it in AR strategy

Added simple "per request" ChecksumPolicy override feature to maven
specific repositories (as ChecksumPolicy itself is maven specific).
Using it one can "relax" the policy for single request.

Making use of it in RemotePrefixFileStrategy, to relax
the policy if its STRICT to one step below (STRICT_IF_EXISTS).

Added UT that validates the change. UT will fail if relevant
changes are commented out from RemotePrefixFileStrategy,
NXCM-5188: Removed temptation by adding inline explanation

I was tempted to change these methods, but finally figured
it's completely unneeded.

Comment explains why.
NXCM-5188: Typo in comment
NXCM-5194: G level metadata merge duplicates entries

Reason was as entry equality was checked by comparing all
three properties of the Plugin: prefix, artifactId and name.

This commit "improves" this, by performing comparison
on prefix and artifactId only. This means that
duplication will not happen anymore on new
deploys, and will be corrected if maven metadata
rebuild task is run against repository. Still,
the one case "changing prefix" mentioned
in related issue is NOT fixed by this change.

Related:
https://issues.sonatype.org/browse/NEXUS-4448
Fix Maven2InfoPanel.js requirejs dependencies
NXCM-5194: Renamed badly named method
Merge pull request #791 from sonatype/file-list-io-error

[2.5] NEXUS-5612 File listing should fail in case of IOEx
NXCM-5194: Applied comments

From Alin to simplify the method.
Merge pull request #807 from sonatype/nxcm-5194-dupe-g-repository-metadata

NXCM-5194: G level metadata merge creates duplicated entries
NXCM-5188: Checksum policy set to IGNORE for prefix requests

As the transport integrity here has small chances to slip in
as prefix file will be processed, and hence, checked/validated
Merge pull request #806 from sonatype/nxcm-5188-checkum-policy-blocks-prefix-list

Checkum policy blocks prefix list
Merge branch 'master' into NEXUS-5660_preferIPv4Stack
move system property to wrapper.conf
NEXUS-5660 - java.net.preferIPv4Stack=true should be set by default in case Java 7+ or JMX is used with Nexus