Introduce TTL option for dynamic queues

[lrascao]

Since the possibility of dynamic queues, we are now able to have a lot of them (one per user for example), they all make use of timers to replenish their token buckets so this may introduce heavy load on pre-OTP18 timer wheels. Perhaps a TTL option could be provided to the queue upon creation, after this TTL expires the queue dies. This implies that the queue creator must be made aware of this and invalidate it's reference to the queue, could this be an interesting option? i'm available to put forward a PR with this

[jlouis]

This is a nice idea. What is your implementation strategy, before embarking on it?

[jlouis]

Ok, having given this some thought:

Observation 1:

We don't need to poll all the time. We just need to poll as long as there is a flow and the token bucket is not full. Once the bucket fills up, there is nothing to do until someone invokes the queue and makes changes on the queue. In turn, idle queues will not need any kind of extra work.

Observation 2:

Building on Observation 1, it is easy to add a timeout by simply using the form {noreply, State, State#state.idle_timeout}. If this triggers, we can close down the queue.

Observation 3:

If we want to watch a queue, it is desirable to do so by using a monitor. This is safe, insofar the monitoring client will always be notified if the queue disappears. We should probably shut down with {shutdown, idle} to notify the user of the monitor the exit reason in a graceful way. This behaviour should also be documented.

I'm not sure how far back {shutdown, Term} is supported. This should be checked, but I'd hope at least release 17 supports it.