Different strategy for working with RabbitMQ messages.

First things first

Moving away from enqueue was nice 👍
Now the library is more inline with Laravel and the Queue API. 👍
I think with V10 we moved forward how it was designed to work. 👍

Why this enhancement

RabbitMQ is an advanced message broker. The documentation says it all...
The way the V10 currently works, no advanced scenarios can be used. We only have the opertunity to publish messages to a queue directly.
When developers or sys admins, want a more advanced approach by defining topics or even more advanced scenarios in RabbitMQ, the V10 version does not provide a solution.
It basically only provides in the very basics of queuing.

Working with producers / consumers / exchanges and queues

With this in mind:

• Publishing messages is always against an exchange.
• All queues are by default bound to the amq.direct exchange.
• When messages go over an specified exchange the queue becomes a routing-key.
• Do not try to recreate exchanges/queues when they already exits, just publish.
• Consumers aren't aware how the messages end-up in a queue.
• Consumers only know the queue they are bound to.
• Consumers must wait or timeout when no queue or messages exist.

The rework

In pull request #304 i'll try to bring back some of rabbitmq's features and the previous versions of this Library. Where I do complement the use of exchanges and try to fix all issues people have with the new V10 version.

The list of fixes and features:

• Added ability to use a exchange other than direct delivery.
• Added ability to prioritize delayed messages, when put back to the queue.
• Added auto delete of delayQueues.
• Added ability to reroute messages when failed.
• Fixed when to acknowledge or decline messages.
• Fixed attempts() when multiple delay values are used. issue
• Fixed death worker loop, when queues are missing. comment
• Fixed issue #305
• Fixed issue #302
• Fixed issue #301
• Fixed issue #299