RESTful webservice to receive notifications of artifact uploads

[kevstigneev]

Expected result:

• The plugin exposes a webservice endpoint to receive artifact upload notifications.
• Notifications come in a form of HTTP POST requests with artifact coordinates and target repository as a payload.
• Notifications are received in a non-blocking way. Processing is asynchronous.
• The endpoint support authentication.
• The webservice requires authorizarion. Access control goes through the usual Nexus facilities.

[kevstigneev]

At pull request #9 the service does not return till the artifact is replicated.
Might cause timeouts for large files.

[kevstigneev]

@alekseysemenov please check if a large (few GB) artifact replication that takes few minutes is handled well. If it does - this task is to be closed.

Fully asyncronous replication has been moved to #19.

[kevstigneev]

@alekseysemenov Please verify the cases

• A Nexus instance receives so many uploads in time so thread pool for notification senders is exhausted. What's happening when another upload arrives? Does it cause a message processing lock?
• A peer Nexus instance is down. What's happening with the primary instance when uploads come?

[kevstigneev]

It appeared that:

• Nexus message processing is blocked when there are more ongoing replications than the thread pool size.
• Nexus message processing is blocked on each upload when number of peers is larger than thread pool size.

Given that this task can be considered "done" if:

• Notification sending does not block message processing thread in any way. I.e. a task to send a notification is queued first and then goes to a thread for execution.
• If the queue is full, an exception is thrown, an error is logged but nothing is blocked on that.

[ctapobep]

What do you mean by message processing? And what are the consequences for Nexus in general?