Before moving the control of live-migration into the conductor,
extract the live-migration control logic into a separate class.

The callback to select_hosts will be replaced by a new
scheduler rpc method in a later changeset.

Part of blueprint live-migration-to-conductor
Change-Id: I6de33ada6dc377e20f8df07da92244f2c150b9fe

Make sure that when scheduling, the instance_type used in filters
contains the 'extra_specs'.  This is a bit ugly, but will get cleaned up
with objects.

Fixes bug 1192331

Change-Id: I3614f3a858840c9561b4e618fc30f3d3ae5ac689

This makes the _poll_unconfirmed_resizes() periodic task use
objects for looking up the instance state information.

This patch also makes compute_confirm_resize() take instance
objects. Although this method will be obsolete after a full
conversion to objects, this makes it send a full instance object
to the conductor manager, which is then converted to a dict for
passing to compute_api (for now). This will allow a more complete
conversion of the use of it to objects, and then the dict hack
will be removed when the method itself goes away.

Related to blueprint unified-object-model

Change-Id: I03c1a28a1bbd9732f803e140e93d214dd5c7792e

Commit 3cf4cb2534c387f287f118d4185d54b1435d3bc0 made the
vol_usage_update() in conductor hack around a stale sqlalchemy
object issue by keeping session active in the current context
until the notification was completed. This layering violation
led to some "creative" tests to try to verify this behavior.

This removes that and refreshes the object before letting it
out of the db/api layer so that all the attributes are present,
thus avoiding the dynamic load during notification.

Change-Id: Ia6ef5cb7f462ff72d170f3af33f2d020ee4d3e3c

This is a first pass at client side version control for rpc.  It allows
you to configure a max version of messages that clients are allowed to
send.  You can find one example of how clients need to adapt in the
conductor rpcapi.  All other changes in rpc apis since the grizzly
release are not applicable to this.

Some future improvements to this could be reporting the versions
supported by running services and having that be discoverable via the
API.  We could also consider allow setting these client side version
caps via the API.  For now, recommended values for these config
options while attempting a rolling upgrade will just have to be documented.

The config options allow specifying specific rpc api version numbers if
desired, but an alias of 'grizzly' is also supported.  So typically at
the start of a rolling upgrade you'd have:

    [upgrade_levels]
    compute=grizzly
    conductor=grizzly
    scheduler=grizzly
    ... etc ...

And as you update all instances of a service, you would remove that bit
from your configuration across the deployment using your config management
system of choice.

DocImpact

Implements blueprint rpc-version-control.

Change-Id: I2c0fd6dd7484c87823846d7c31d6525d93cd1b43