Continuation from #570

[AgeManning]

Description

This is a continuation from #570.

I made a separate PR in case we decide not to go down this direction.

This PR builds a wrapper struct around three queues, whereas #570 uses a single queue.

I think we run into some drawbacks in the single queue system:

1. We lose some efficiency in retain() where we are only searching for a single kind of message, but we must search through all messages (for IDONTWANT) as its a single queue.
2. We lose some control over the queue lengths. The user can customize the non-priority queue length, but on a single queue, high priority messages can consume the entire queue and leave no room for non-priority messages.
3. We are about to introduce a new length cap in the control messages. I think having two lengths and a lot of interleaving and overlapping logic concerns for different messages (i.e we want to cap control messages like graft/prune, we want a different cap for publish and forward, and we want some to be unbounded) all put into a single queue makes the code and reasoning fairly complex.

If we have a queue for each logical concern, the caps, lengths and independent logic I think becomes easier and we gain efficiency when searching for particular messages, as we only search for the message type we are interested in.

This PR attempts to implement a three queue system.