Support MRU poll order for idle resources

[simonbasle]

Motivation

There is currently two flavors of pools, fifo and lifo, but these attributes apply to the order in which pending acquire() are served once a resource becomes available (ie no resource is available and no resource can be created, but several acquire() are attempted).

The reverse situation where resources are idle in the pool when a single acquire() comes in is not impacted by this parameter. Instead, provided there is no pending acquires, the pool always produces idle resources in "fifo" insertion order (effectively equivalent to a Least-Recently-Used order)

Desired solution

Add a way to tune the order in which idle resources are chosen when a new acquire() comes in. At a minimum, the following use case should be covered:

When dealing with a TCP Connection, some remote servers may close the connection if it has been inactive for too long. To avoid even receiving this kind of errors entirely, using a MRU (Most-Recently-Used) order when polling for an idle resource could be beneficial.

This should be achievable by either using a Deque (on which we would either call pollFirst() or pollLast() or some form of PriorityQueue (see #88).

Moving aways from the Reactor MPSC queue also enables iteration, a pre-requisite for background eviction (#86)

Challenges

• The current implementation uses a lock-free MPSC unbounded queue. The alternative must be efficient enough to stand the comparison with that structure.
• Under low demand, a MRU scheme would mean old connections have less chances to be visited, which also means that they will linger in the queue and won't get evicted. This makes Provide automatic background eviction of pooled objects #86 (background eviction) even more important to have, since this increases the symptoms of low pool utilization.

[simonbasle]

Since there is no efficient non-blocking implementation of a PriorityQueue and since fifo/lifo is enough to implement LRU/MRU usage of idle resources, this issue will focus on LRU/MRU. See #88