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>