ApnsServiceCache (or its base AbstractServiceCache) can be refactored so that it will track number of used services/sockets per whole cluster (not only an app-server as of today).

The idea is we will use "ticketing / lease" scenario:

1. at the start of first token batch, we will dump N number of tickets to the queue
2. AbstractServiceCache can lease the ticket from the queue (replacing current AtomicCounter) indicating it has right to create a new service
3. once we want to free the service, we can return the slot to the cache, which will send a ticket back to the queue
4. once the sending process is completed for given variant, a message will be sent to the topic to all subscribers that they can stop their services (replaces current CDI eventing: VariantCompleted, PushMessageCompleted)

The tickets are identified by pushMessageInformationId and variantID and can be thus selected using JMS message property selectors.

The system can be completed with pro-active closing mechanism that stops and frees up services that are not used for given time (e.g. ApnsService is not used for 5 seconds on one node, so we will stop it and allow other nodes to create it its ApnsService for dispatching loaded tokens).