NEXUS-5654 fixed deadlock during concurrent deploy

Propagation of prefix file changes from members to group repositories
was acquiring read-lock on all group members while holding write-lock
on one of the members. Two such changes executed concurrently for
different members of the same group will almost certainly result in
deadlock. Solution is to execution group prefix file update on a
separate thread.

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
Cleanup: removed extra prefix and noscrape paths

There is currently no use case for these extra file paths,
they complicate the code and make proper synchronization
harder to implement.

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
Cleanup: removed separate no-scrape marker file

Changed prefix file format to allow encoding of no-scrape request
using "@ unsupported" directive. Single automatic routing medata
file makes proper synchronization easier to implement and simplifies
overall implementation.

This also eliminated two HEAD requests per remote (due to a bug
original implementation performed HEAD no-scrape file for each
discovery strategy, not once per remote).

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
Fixed wrong RoutingStatusResourceTest initialization sequence

The test was waiting for routing background updates to finish
way too early (before nexus repo manager was started) and was
extremely sensitive to changes auto-routing implementation.

Changed the test to do waiting later during nexus instance
startup. This is still a workaround and the true fix should
wait for a particular event, "repo auto-routing publish state
change" in this case, not for "no backgroup update jobs are
running" as it does now.

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
Cleanup: reconciled autorouting startup and periodic update logic

Automatic routing periodic update logic is now able to initialize
hosted repository prefix path list as needed. No need to do this
explicitly during startup any more.

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
Cleanup: removed unused method parameter

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
NEXUS-5654 fixed endless autorouting initialization restart

Hosted repositories autorouting initialization involves deep walk
of entire repository local storage and is likely to take significant
time for large nexus installations like OSSRH. In attempt to prevent
lost-update race between artifact deploy/delete and hosted repositry
autorouting initiazation, deploy/delete unconditionally restarted
initization which could lead to apparently endless initialization if
time between deployment is less than initiazation time (again, not
impossible for larger nexus installations).

The fix is to never restart initialization logic during artifact
deploy. This is not bulletproof and can result in missing prefix
entries if deployment of new top-level groupId happens after certain
point during repository autorouting initiazation, but I believe
this is going to be very unlikely (assumption is that new top
groupIds are very rare for populated hosted repositories and
initiazation is very quick for new/empty hosted repositories). If
this does happen, the workaround is to delete prefix file and
wait for 1hr for another initilization attempt to take place.

In order to completely eliminate possibility of race between
artifact deploy and autorouting initiazation we'd need to extend
RepositoryItemUidLock API to allow lock-with-timeout, something
I decided was too tricky and risky this late in 2.4 cycle.

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
NEXUS-5654 fixed race between offer/revoke and initializePrefixFile

The race was only possible if a new repository was provisioned and
deploys to the new repository happened very close in time. Extremely
unlikely unless repository provisioning and deployment are executed
by the same script.

The fix is to remove redundant 'unpublish' call during
initializePrefixFile.

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>
Cleanup: renamed and documented purpose of ConstrainedExecutor

Signed-off-by: Igor Fedorenko <igor@ifedorenko.com>