Be less confusing about notification states

Depending on the way we snake through send_update we might end up in
_send_instance_update_notification without the vm or task states. The
issue being that we always send those states to the notification
payload. So we are actually producing notifications with None(None) =>
which is clearly not right.

This whole notification path should probably be refactored to prevent
this threading from happening, but in the mean time this will at least
mean that we aren't creating blatantly wrong notifications.

Add unit tests for the new behavior.

Change-Id: I5092880647a4ac826376396610599dab99efb08e
Closes-Bug: #1204169
Revert "libvirt: Uses correct imagebackend for configdrive"

This reverts commit 0b01e846d40f3b343da9ebe1dae89cca8bc2ac66.

We  should not be adding instance specific disks with configuration
information like passwords into a shared cache. I think this is the
wrong way of moving the config drive disk image into an arbitrary
backend store.

Change-Id: I1376ef5f3fcbd66d916ff9442efea0f756dd42da
Add further debug logging for multiprocess test

In order to track down where we are stalling add some additional
informational logging into the cleanup path.

Change-Id: Ia12b1049b3a63851bde69cb5f7c3fe31b0d12c41
Related-Bug: #1357578
Remove the AUDIT log message about loaded ext

Finally, I got to a boiling point when having to scroll through endless
and pointless log.AUDIT messages about "Loading extension XXX" in the
startup messages for the os-api endpoints. This patch gets rid of this
extreme annoyance.

Change-Id: Ia47f6afae89d145ade2a940d4720f5977fde2204
Merge "Be less confusing about notification states"
Merge "Add further debug logging for multiprocess test"
Merge "Remove the AUDIT log message about loaded ext"
Merge "Revert "libvirt: Uses correct imagebackend for configdrive""