Adjust the order of notification for shelve instance

When shelve instance, if CONF.shelved_offload_time == 0, then the
notification order for shelve_instance() is as following:
1) compute.instance.shelve.start
2) compute.instance.shelve_offload.start
3) compute.instance.shelve_offload.end
4) compute.instance.shelve.end

This order is not correct, as actually before shelve_offload.start,
the instance was already reached shelve.end, so we should adjust the
order of notification for shelve instance as following:
1) compute.instance.shelve.start
2) compute.instance.shelve.end
3) compute.instance.shelve_offload.start
4) compute.instance.shelve_offload.end

Change-Id: I6e075b3f29e1c3f641ab1e459e1fbe3b05869a9a
Closes-Bug: #1248802
Improved debug ability for log message of cold migration

When cold migration failed because of nova scheduler return no
valid host, conductor only log no valid host, but did not specify
which instance failed.

This patch was specifying instance in the failure log for cold
migration.

Change-Id: Ia9e42f8f253323fb35a58e0be2a24ab043204d29
Fix some i18n issue in nova/compute/manager.py

Some exceptions in nova compute manager did not follow i18n coding
style, just fix them.

Change-Id: I9cc18c05419508232062c749c0f9740c5241469d
Merge "Improved debug ability for log message of cold migration"
Merge "Adjust the order of notification for shelve instance"
Merge "Fix some i18n issue in nova/compute/manager.py"
XenAPI: Speedup host_ref cannot change - get it once

The host we run on is fixed - getting this each time from XAPI
is expensive

Change-Id: Ifee9a778f3ed855ef52b001de3fc2ebbd0b972cf
XenAPI: get_info was very expensive

Getting the whole VM record is expensive and slowed down Tempest tests
significantly.

Change-Id: I93bcef5b692a531aac41518dc29d5d4f46cded65
XenAPI: Tidy calls to get_all_ref_and_rec

Use in fewer places, and where it is still used, use the more
efficient get_all_records

Change-Id: I4725c3f1fdebdf1737941cb7db69b19afb22df9f
XenAPI: Speedup get_vhd_parent_uuid

In many cases the VDI record has already been retrieved.
Use it rather than expensively getting a new VDI record from XAPI.

Change-Id: I469e2a415c1f1924010f47d3927ca18c45a7b8f8
XenAPI: Reduce calls to sr_scan

These are expensive and not needed in the scenarios here

Change-Id: I2aeda6e2b7a001ac23ee486495592e242bc078ba
XenAPI: get_XYZ is faster than get_record

Replace multiple calls to use get_XYZ in preference.

Change-Id: I52e20c4f4c9d6a6ad019694916ee057cc96b18a6