Xen: Attempt to find and cleanup orphaned SR during delete

Before some patches merged to better handle failures to boot an instance
from a volume it was possible to have an attached volume with an SR and
plugged PBD but no VM.  And the destroy method in xenapi short circuits
if no VM is present because everything is looked up from there in order
to be cleaned up.

This adds a check to see if a volume is supposed to be attached during
destroy if no VM is present and attempts to look it up via the SR uuid
and clean it up.

I would like to say that this patch is unnecessary, as it's sort of
hackish, but it's possible that some deployments have instances in this
state and this will allow them to cleanup without manually running
commands on the hypervisor.

Closes-bug: #1367918
Change-Id: I7745af7e22164a96af800ae796bda077e49bf291
Add Quota roll back for deallocate fix ip in nova-network

in nova-network, deallocate_fixed_ip function reserve quota
first then do deallocate operations if any operation failed,
the quota reserve operation need to be rollback.

Change-Id: If57d2b8a24b2f6ed3d90a1357e89782194df013c
Closes-Bug: #1284930
Pass block device info in pre_live_migration

In case of block migration, this adds block device information to the
disk information handled by pre_live_migration, so that at least in the
case of libvirt no spurious files are created corresponding to volumes.

Co-Authored-By: florent.flament@cloudwatt.com
Change-Id: I373001e0ef0e4fe4ab900d399756f27101cfe5c8
Closes-Bug: 1376586
Allow force-delete irrespective of VM task_state

Cannot delete vm instance if duplicate delete requests are sent.

When user sends request to delete an instance, its task_state gets
changed to 'deleting' state. When an instance task_state is already in
'deleting' state and if at that moment the rabbitmq-server get crashed
by some reasons, then the instance task_state remains in 'deleting'
state and user won't be able to delete the instance forever.

At this moment, there is only one way to delete the instances, whose
task_state is in 'deleting' state, by restarting the nova-compute
services where these instances are running.

To avoid restarting the nova-compute service manually, modified the
force-delete api to allow instance deletion irrespective of
instance task_state.

Added new module to use delete_types as constants and replaced all
delete_type string occurances with new constants.

Closes-Bug: #1308342

Change-Id: I4d0e47662a80109ef9622d85455587d487e47c01
Merge "Add Quota roll back for deallocate fix ip in nova-network"
Merge "Pass block device info in pre_live_migration"
Merge "Xen: Attempt to find and cleanup orphaned SR during delete"
Merge "Allow force-delete irrespective of VM task_state"