Oslo/blueprints/messaging-decouple-cfg

= Rationale =

oslo.messaging is really tight to oslo.config. A lot of places in the code asssumes that a configuration object is present to read the configuration file.

It would be great to move this configuration object usage out of the API so you can use it without having this object, but passing parameters to methods and constructors. That would allow applications to use oslo.messaging without using oslo.config

Nevertheless, as OpenStack is the primary consumer of this library, having a out-of-the-box way of using a configuration file to get the right transport objects is mandatory.

= Plan =

The plan from high in the sky, siting on the cloud is:
 * 1) Allow to use oslo.messaging even if no oslo.config object is provided
 * 2) Decouple oslo.config usage from the general code base, and import it in only one specific oslo.messaging module.

The detailed plan would be:
 * 1) Remove configuration usage from executors. The configuration options will be passed as an options dict to oslo.messaging.server.MessageHandlingServer that will be used as kwargs for the driver.
 * 2) Allow oslo.messaging drivers listed under oslo.messaging.drivers entry point to receive custom options. Different drivers might have different options (connection retries…). Options will be read as kwargs in the prototype, and then from the conf object if they are not specified in the kwargs. This is already partially the case, see the option default_exchange for example.
 * 3) Allow oslo.messaging.transport.TransportURL class to be used without a configuration object, and having the options parsed from the URL query parameters.
 * 4) Remove the conf parameter from oslo.messaging.transport.get_transport, and create a function oslo.messaging.transport.get_transport_from_conf(conf) that will rely on configuration object rather than an URL. The config object will be converted to a dict of options, that will be passed as kwargs of the driver at creation time (like done with query parameters)
 * 5) Remove configuration usage from the driver as they are now getting the options from the configuration object properly if oslo.messaging.transport.get_transport_from_conf(conf) is used, or from the parsed URL otherwise.
 * 6) Most options registered are needed for legacy compatibility with OpenStack configuration files. I suggest we move them into a special oslo.messaging module where we could also move oslo.messaging.transport.get_transport_from_conf(conf) to completely isolate the configuration part handling.

The same pattern should apply for notification, though I didn't checked extensively yet.