It was possible to deadlock your policy by triggering queue
length/emptiness checks conurrently with the queue consumer thread.
Let's make it more explicitly clear which methods cannot be used that
way by making their mutex acquisition non-blocking and raise an error.
In addition, let's improve the close method so that it doesn't require
exclusive access to the consumer side of the queue.
Provide a shutdown_logging event that can be used to explicitly close
queues on shutdown, if that is appropriate for your use case.
This function allows defining a non-durable, non-persistent, in-memory
queue that is intended to be used as glue when building up more advanced
processing flows within kumomta.
The intent is that the queue is processed from within a task spawned via
`spawn_task`.
Wez Furlong