Work on removing polling from RabbitMQ transport

[zlepper]

Hopefully implementation for rebus-org/Rebus#917

I hope by starting this we can start some discussion about how to implement it. Quite a few of the tests are failing now due to timeouts, which I assume is because the Receive method never returns.

---

Rebus is MIT-licensed. The code submitted in this pull request needs to carry the MIT license too. By leaving this text in, I hereby acknowledge that the code submitted in the pull request has the MIT license and can be merged with the Rebus codebase.

[zlepper]

I just cannot make this work as I want, so i'm closing this.

[mookid8000]

Sorry to hear about that 😐

[zlepper]

No worries :)

Rebus expects to be able to poll the transport in a lot of places, and suddenly having the transport just hanging until Rebus gets a response doesn't really work out that well. There also seems to be some pushing already, so it's not all bad :) I would just have loved to get rid of the polling entirely, we didn't have to waste cpu cycles waking to check all the time.

[mookid8000]

(..) waste cpu cycles waking to check all the time

Yeah well, while it does of course consume a little bit of CPU, I don't think it's that bad.... the driver has some kind of blocking + timeout on its polling method, meaning that Rebus does not call it that often when running idle. If would of course have been ideal if messages could be pushed

[zlepper]

The problem is we have to decrease the polling interval to make it not take a while the first time an event comes in, in a while, at least in my experimentation.