A formal API proposal...

So I think this is a decent initial proposal... there is obviously still features missing, but I hope the concepts are reasonably sound.

There is some polling the queue in this proposal, but most of that can be avoided by listening to RabbitMQ and doing one poll to get messages that maybe been missed. Initially, I suggest that we poll and learn to rely on RabbitMQ later, I'm very reluctant to store application state in RabbitMQ queues, for this reason this proposal only defines exchanges.

In the future, when the whole thing becomes less dynamic and volatile we may want to define named queues too. But for now exclusive auto-deleting queues won't lock us in too much and make upgrades hard.

My only minor concern with this design is that the RabbitMQ exchanges can be hard to change, we can always add more or give the messages more properties, but removing exchanges could bring complications if both workers and provisioners relies on them. Anyways, I hope they are sufficiently simple to not cause problems.