Provide support like rpc_await for publish to allow for caller to check for confirms

[sdebnath]

Creating an issue as a discussion placeholder for implementing support similar to rpc_await for publish. This will allow client scenarios such as

1) begin transaction with some db 2) publish a message to RabbitMQ to do some heavy work somewhere else (call it publish_async?) 3) do some local work 4) check with turtle via publish_await to see if rabbitmq confirmed receipt 5) if confirmed, commit tx, else rollback 6) party.

[jlouis]

First a caveat for the reader: under network partitions, I would not trust RabbitMQ to provide delivery guarantees. The situation is murky and the guarantees provided are not entirely clear to me. That said, however...

I think an async publication makes a lot of sense. Currently, we block the caller until publication goes through and then we unblock the caller. In the proposed solution, you can do other things "in between". One way to go at it, is to generalize the reply_to_caller path in the publisher:

• Rather than blocking the caller, return immediately, as it it was an RPC style message, but store a "unacked" notion in the same style as an rpc just tagged as a confirmer.
• The caller awaits as you do with an RPC, in publish_await and follow the same style.
• Generalization is not entirely symmetric however: The RPC unblocks on a confirm and uses handle_deliver to handle the case of delivery out-of-order. In this case, reply_to_callers should be updated so it can send standard messages to the caller.
• The initial call should probably be a call rather than a cast to we can return an opaque token/tag.