Proton routing prototype

This is an attempt to find out what "proton routing" could mean by fleshing out
some specific example cases. The basic idea is a "distributed broker" where
broker functionality is achieved by a collection of collaborating AMQP nodes.

The idea is to have a "container" process with plug-ins that provide AMQP nodes
with different capabilities. Essentially a pluggable broker.

Two initial use cases to implement:

1. Distributed Topic
2. Distributed work queue

The goal is to prototype something that is potentially useful and complicated
enough to hash out design issues. There are many other use cases that
could/should be addressed but theses two seem like a good starting point.

The initial prototype would be in python for speed of development. Final
production verrsion may be in other language(s)

Distributed topic

A set of containers is started, loading topic nodes. Nodes are linked together
via configuration and/or a management tool.

Subscribers subscribe to a topic using the 0.10 topic wildcard format (unless
there's a better suggestion).

Publishers publish messsages to a topic. Topic is addressed by name in the
sender/receiver address (is there a better place to put this address in the
message headers?)

Subscribers and publishers can connect to any node in the network. A message
published at any node will be routed to all subscribers regardless of which node
they are subscribed to.

Node types:

• subscribe nodes: subscribers send a specially formatted message with a wildcard
• subscription-status nodes: inform other nodes of local subscriptions.
• deal with loops and multiple routes in the network.
• publish nodes: route only to interested neighbours.

It would be nice to make the routing dynamic, so e.g. we can kill one container
and messages will be automatically redirected via another path.

Distributed work queue

A logical "queue" implemented by multiple containers linked together. Each
container can have producers and consumers of the queue. Whenever possible a
work item posted on a container should be given to a consumer on the same
container. When this is not possible (no local consumers or consumers too busy)
work items are routed to another container.

Note this queue does not guarantee ordered delivery of messages like a normal
queue. It will do "mostly ordered" delievery, the degree of disorder will depend
on the amount of re-routing that has to be done.

Constraints

• don't lose any work items.
• don't process the same item twice
• try to balance work across all containers.

Node types:

• publish: publishers send messages here.
• distributed status: so containers know where to route work items.
• subscription: consumers send special message to subscribe.