Properly reconnect subscribing clients when QPID broker restarts

Fixes bug 1251757

This is a cherrypick of oslo-incubator:
e227c0ed7e0ed1f9b8d029336f8aeb60e38c23df

From the oslo-incubator bug:
When the QPID broker is restarted (or fails over), subscribed clients
will attempt to re-establish their connections.  In the case of fanout
subscriptions, this reconnection functionality is broken. For version
1 topologies, the clients attempt to reconnect twice to the same
exclusive address - which is illegal.  In the case of version 2
topologies, the address parsing is broken and an illegal address is
created on reconnect.  This fix avoids the problem by removing the
special-case reconnect code that manages UUID addresses; it is
unnecessary as the QPID broker will generate unique queue names
automatically when the clients reconnect.

Change-Id: If966bb25e49b5837293a1bb181bbb02086599d81
Create a shared queue for QPID topic consumers

Fixes bug 1257293

This is a cherrypick of oslo-incubator:
ef406a21782134aeefb944f74b3f1a47d6169318

From the oslo-incubator commit:
When multiple RPC servers (consumers) are subscribed to the same RPC
topic, a single RPC request to that topic should be received by only
one of the consumers.  A bug in the QPID driver caused every consumer
to receive a copy of the RPC request.  This bug affects only Topology
version 2.  This patch will cause a single queue to be created for
each topic, and shared among all consumers of that topic.  This
results in each RPC request being received by only one consumer,
in turn across all the competing consumers.

Change-Id: I97c6eb5fe63322ab70716c63074818ff1b6ea82b
Merge "Properly reconnect subscribing clients when QPID broker restarts"
Merge "Create a shared queue for QPID topic consumers"