Priority Linked Blocking Deque Implementation (not intended to be merged)

[mpoemsl]

This PR implements request priorisation by replacing LinkedBlockingDeque in Model.java with a wrapper of multiple LinkedBlockingDeques (one for each priority class).

This PR builds on TorchServe 0.7.1. The behavior is as explained in #88. The implementation of this behavior is achieved with these changes:

1. Jobs parse an int priority from the HTTP header X-Priority (default priority class is 0) and extend the Prioritisable interface (getter and setter for priority)
2. Models store Jobs in a new class PriorityLinkedBlockingDeque which wraps multiple LinkedBlockingDeques (one for each priority class, the number of which is specified via TS_NUMBER_OF_PRIORITIES)
3. PriorityLinkedBlockingDeque implements all methods of LinkedBlockingDeque that are used in TorchServe, namely addFirst and offer for insertion and poll for extraction.
4. Insertion is forwarded to the appropriate LinkedBlockingDeque for a Job's priority (if it is full, a ServiceUnavailableException is thrown)
5. Extraction follows this order to find a non-empty deque:
   5.1. Deque for priority 0
   5.2. Deque for sampled priority >0
   5.3. All other deques
   If all deques are empty, poll sampled deque until next insertion in any deque.
6. A new metric RequestPriority logs the priority of each request.

[simonschoelly]

Not that it is incorrect, but maybe it is a bit unnatural to use a header instead of the body for the priority? But if it is the only way, then lets keep it.

I am also not sure about the name X-Priority - apparently that header is already used in some cases for emails.
In the past, I started using the convention of prefixing headers with X-TS- so that it is clear, that it is our own header.

[mpoemsl]

That's a good idea, I'll change it to X-TS-. I think at this point the request body is not yet parsed, so it has to be a header unless we want introduce overhead at the pre-queueing stage.

[pypae]

If we wanted to be future proof, we probably had to implement all interfaces implemented by LinkedBlockingDeque. But I guess just implementing the methods that are actually used is okay for now.