Merge pull request #5 from FlaPer87/messaging

Fix docstring
Pass a context dict

Plumb a context dict all the way through the stack.

This is ugly, but:

  - it seems valid to have generic support for a message context
    that is implicitly included in all RPC interfaces

  - rabbit/qpid serialize the context differently, so we really
    need to pass it all the way down to the transport to continue
    to support this

  - notifications also send a context, so it's not rpc specific

Change-Id: I8dae83d73b78a3ab74133bf4c67817706e6d45c7
Add IncomingMessage abstraction

When an executor polls for a message, the driver needs to return the
request context and the message.

Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.

In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.

In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.

To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.

To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.

Change-Id: Ie3b9385c2d6c8335d8c307e3bdeeeba8a0660d50
Add some notes

Change-Id: I0c08a816a4da168b39fbd64a8e876b916fd1ef0e
Starting to mock this up
Rebased to latest messaging
working on consumers
Starting to port consumers