Sending on an unconnected zmq socket will now drop the message.

The rational is that if the message is important then an extra
acknowledgement mechanism should be added on top to ensure that
message was properly received. This also fixes several issues where a
user would call connect but the service is not available.

Note that yes this is starting to look like we're re-implementing tcp
but it's necessary to handle the complexity of the zookeeper discovery
mechanism.
ZmqMultipleNamedClientBusProxy should no longer call the connection handler when the service is unavailable.

Turns out that this is pretty complicated to get right because we
can't call the handler while the lock is held which mean that the
naive forwarding implementation won't work. Instead we need a custom
functor to act as the callback which handles a lock-free state machine
whose behaviour changes depending on whether we're in the locked
section or not.

Note that we should eventually try to simply remove the lock by
funnelling all events (zmq and connect calls) through message loop.