Rework virt.xenapi's concurrency model.  There were many places where we were inadvertently blocking the reactor thread.  The reworking puts all calls to XenAPI on background threads, so that they won't block the reactor thread.
Rework virt.xenapi's concurrency model.  There were many places where we were
inadvertently blocking the reactor thread.  The reworking puts all calls to
XenAPI on background threads, so that they won't block the reactor thread.

Long-lived operations (VM start, reboot, etc) are invoked asynchronously
at the XenAPI level (Async.VM.start, etc).  These return a XenAPI task.  We
relinquish the background thread at this point, so as not to hold threads in
the pool for too long, and use reactor.callLater to poll the task.

This combination of techniques means that we don't block the reactor thread at
all, and at the same time we don't hold lots of threads waiting for
long-running operations.

There is a FIXME in here: get_info does not conform to these new rules.
Changes are required in compute.service before we can make get_info
non-blocking.

n0ano/gantt,n0ano/gantt