Prefer instance in reboot_instance.

Now that we're passed through an instance, or something which is
immediately turned into an instance, we should prefer using the full
instance inside compute methods. This is especially useful for log
messages, as it allows users to format the messages more than they
can if only the UUID is passed.

Change-Id: I29370f33a63817f3e45d453499bd46131b947d7e
Instance cleanups from detach_volumes.

We can just use members of the instance dictionary without turning
them into local variables, as we don't need to populate instance_uuid
manually, as that is done by the @checks_instance_lock decorator.

Change-Id: I2046d5688c2f5122624dc338680b7ddd850ed330
Xen: VHD sequence validation should handle swap.

The VHD sequence validation code was erroneously counting `swap.vhd`,
which caused it to raise an exception when a corresponding numbered VHD
was not found.

The fix is to simply ignore the `swap.vhd` file.

Other unknown VHDs will generate an exception, but from a
sanity-checking perspective, this is a Good Thing(tm).

Fixes bug 1030939

Change-Id: Ic82ae27a4af7ea8f7669fd006aea1a310b691218
Avoid associating floating IP with two instances.

Addresses LP 1029911.

Associating an already-associated floating IP with another instance
results in the floating IP being first disassociated from the original
instance and then associated with the second instance.

However when this transfer of the floating IP to the second instance
occurs, the network info held in the database instance info cache was
previously only updated for the second instance (via the
@nova.network.api.refresh_cache decorator).

As a result, the floating IP was initially reported as being associated
with *both* instances. This misreporting is temporary - eventually the
periodic heal_instance_info_cache task will roll around and purge the
inaccurante network info for the original instance. However depending
on the frequency configured for this task and the size of the instance
population, it could take a while for the refresh to occur.

This issue is addressed by immediately purging the obsolute network info
when the reassignment occurs.

Change-Id: Ibfb04997ff4a983d144d81350857cb07475aff54
Use event.listen() instead of deprecated listeners kwarg

Fixes bug 1031405

The listeners kwarg is deprecated in SQLAlchemy 0.7.0. Since 0.7.3 is
the minimum required version of SQLAlchemy, use the new event.listen()
API instead.

Change-Id: I3d2bd2e65dbc6787d1c9b69ffd0bcff85c157869
Merge "Xen: VHD sequence validation should handle swap."
Merge "Avoid associating floating IP with two instances."
Merge "Prefer instance in reboot_instance."
Merge "Use event.listen() instead of deprecated listeners kwarg"
Merge "Instance cleanups from detach_volumes."
Partially revert "Remove unused scheduler functions"

This partially reverts commit 2aaa3d2860eed7574c5df64a8ceeb8a6adf23460.

The problem pointed out by this bug is that these changes introduce a
non-backwards compatibile change to the schedulre rpc API.  There are a
couple of acceptable ways to deal with this:

1) Leave most of the code and only remove the client side.  This means
   that a message sent from an earlier version will still work.  This is
   the ideal situation for almost *all* changes to rpc APIs.  We have to
   make a habit of this to eventually be able to support rolling
   upgrades.

2) Leave the manager methods, but simply have them raise an exception.
   This is a bit better than removing the method because the error
   can be made more explicit and obvious.  Otherwise, the operator will
   get "no such method" rpc exceptions, which will seem a bit more
   bizzare.

   An example of when this option makes sense is commit
   cac332c39645286a11c009094a86f62d02752183.  This patch refactored the
   live migration code is such a significant way that making it
   backwards compatibile seemed rather difficult to do.  The old rpc
   methods stuck around but just raise an exception.  The potential
   failure is just that live migration would fail, but the exception
   makes it obvious that an upgrade must be completed for live migration
   to work.

The current patch implements #2 in the case of get_service_capabilities,
since it hasn't been used since pre-essex.  Approach #2 is taken for
get_host_list() as well.  It was used until fairly recently, but was
broken, including being broken in Essex.  The fix that went into Essex
for this makes it no longer use RPC.

Fix bug 1029262.

Change-Id: I74c7d2a3e88b3a4f114e7da62c56f0481ee64a64