AMQP 1.0 client: make it easier to pass in a virtual host

[michaelklishin]

while AMQP 1.0 does not have the concept of virtual hosts, RabbitMQ still does, and so do shovels
and other components.

Currently the way to pass a virtual host is via
a query parameter named 'hostname', which is
very counterintuitive to most users.

With this PR, there are now two better options:

1. The URI path, with the leading slash stripped off
2. The 'vhost' query parameter which is formatted correctly

Both still feed the 'hostname' connection parameter but are much easier to guess and remember
for, say, AMQP 1.0 Shovel users.

[michaelklishin]

I don't feel strongly about the URI path segment part, it can be rolled back. But asking the user to pass in a hostname via query parameters to pass in the virtual host is very counterintuitive.

[lukebakken]

👍

[kjnilsson]

I don't think this is a good change. The client is a generic AMQP client not a RabbitMQ specific wrapper. There is no vhost parameter in the AMQP open frame.

[michaelklishin]

@kjnilsson we do not have a different client to use for AMQP 1.0 shovels. With this change, nothing breaks for those who use this client with another AMQP 1.0 broker.

Our current "solution" for specifying a virtual host is incredibly confusing. At the very least we should support vhost in query strings instead of hostname set to vhost:{value}.

[michaelklishin]

The conclusion is: there are plans to change way we propagate this additional piece of information from the AMQP 1.0 Erlang client to the AMQP 1.0 implementation in RabbitMQ (the change won't affect other AMQP 1.0 brokers).

We'd still need a simplification of URI parsing, possibly in the Shovel plugin, but the hostname field is a part of the AMQP 1.0 documentation and some believe that AMQP 1.0 users must read it, or at least read an overview of sorts.

I'll update Shovel guides a bit to make extra clear what needs to be done at the moment, a hostname URI query parameter must be set to vhost:{name}.