Use a more accurate max_delay for reconnects

In an HA deployment, a 60 seconds delay between reconnects can be quite
problematic. This patch changes the delay calculation by setting the max
delay to 5s and by changing the way it is increased.

Unfortunately, this is one of the places where both our main drivers are
not consistent. Rabbit's driver uses configuration parameters for this
whereas qpid's driver has never had one. However, I would prefer not
adding configuration paremeters to qpid's driver for the following
reasons:

    1. Most of OpenStack services depend on the messaging layer, hence
    they need it to be available. A 5s delay seems to be reasonable and
    I could argue the need of tune it further. Although so frequent
    reconnects can add load to the network, that wouldn't be the main
    issue if one of the brokers go down.
    2. We're trying to move away from configuration options towards using
    transport URL. This path is still not clear and I would
    prefer avoiding adding new options until we clear it out.

(the patch is synced from oslo-incubator)

Change-Id: I537015f452eb770acba41fdedfe221628f52a920
Closes-bug: #1281148
Adds Hyper-V utils methods

Adds Hyper-V utils methods which will be used in the next commit.

(cherry picked from commit c823016d31b36c10cb6faafcce68a1b98f4dc345)

Partial-Bug: #1263766
Change-Id: I7556001557cd013c10b7f883dbf371afa8d09626
Fixes Hyper-V port metrics enabling after service restart

(cherry picked from commit 492190aae01b6587be9e4280a819e2d5a1fdbf97)

Closes-Bug: #1263766
Change-Id: I48fb5389b6049641ca2649990e81e94e4c45ef7f
Qpid, RabbitMQ: advance thru the list of brokers on reconnect

When using multiple brokers, we don't want to immediately retry failed
connection for the same failed broker. This was not the case in
existing implementation though, where we've always attempted to
reconnect starting from the first broker in the list of candidates. So
if the first broker failed, we initiated reconnect to the same failed
broker.

This change makes reconnect() implementation to select the next broker
in the list. This also means that non-failure reconnect attempts will
also switch the current broker. All in all, users should not rely on
any particular order to use brokers from the list, so this should not
constitute an issue.

This sync includes the following fixes for HA deployments:
* Ia148baa6e1ec632789ac3621c85173c2c16f3918
* I67923cb024bbd143edc8edccf35b9b400df31eb3

Change-Id: I77be95dd2db4546297d597032055459a12b52cfa
Closes-Bug: 1261631
Merge "Qpid, RabbitMQ: advance thru the list of brokers on reconnect" into stable/havana
Merge "Adds Hyper-V utils methods" into stable/havana
Merge "Fixes Hyper-V port metrics enabling after service restart" into stable/havana
Subnets should be set as lazy='join'

Currently if one does a net-list tons of queries are issued against the
database as the default query mode is 'select' which performs a query when
the field is actually accessed. In this patch I change the the mode to
'joined' so subnets are loaded as the networks are loaded. Usually, there
are only 1 or 2 subnets on a network so loading this data shouldn't hurt.
This patch in my setup with 5000 networks reduces the net-list call from 27
seconds to 7! Woot Woot :)

Change-Id: I10eec4d79b522dfd685d3d2aa93a8d643104bba7
Closes-bug: 1298053
(cherry picked from commit cbeda85fe5284d2ec0ba39976cdf6ffcdfbdd84a)
Merge "Use a more accurate max_delay for reconnects" into stable/havana
Merge "Subnets should be set as lazy='join'" into stable/havana
Merge branch 'stable/havana' of https://github.com/openstack/quantum into havana/stable