Properly reconnect subscribing clients when QPID broker restarts

Fixes bug 1251757

This is a cherrypick of oslo-incubator:
55678c7ab7fbc1b2beb428d046bb4162f23b0a53

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:
e355fa3a9f49ff524ce98d1263a784b5a7929dfb

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" into stable/havana
Merge "Create a shared queue for QPID topic consumers" into stable/havana