CA-100511: Don't fail SXM when guests are shutdown during migration

If, during the VDI copy to the remote, the guest is shutdown then, when it
comes to moving the domain, Xenops will complain that the domain doesn't exist.
We had already desinged to handle this case but the exception catch needed to
be broadened to match the new "extra" TypedTable used for the VM metadata.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CA-120529: Wait for receiver in X-host VDI.copy

The sender was completing the VDI.copy operation after it had sent the last of
the data. This meant that any subsequent operations on the new VDI could fail
with VDI_IN_USE because the datapath on the receiver had yet to be destroyed.

Now we forward the task to the receiving host and wait for it to set it as
complete.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
 CA-120529: Propagate VDI.copy receiver failures

If the receiver fails but the sender has already sent all its data then it
would have deemed the copy a success. This is dangerous since we can end up
with VDI corruption on the receiver and the impression that the copy was
successful.

Now we re-raise any errors encountered on the receiver back on the sender side
in the case of cross-host VDI.copy.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CA-127975: Run sparse_dd with new subtask during cross-host VDI.copy

Previously sparse_dd (and the receiving import_raw_vdi operation)
re-used the VDI.copy task, marking it complete once the import had
finished.

This caused problems with cross-host VM.copy, as the VM.copy operation
would also watch the VDI.copy task for completion. The VM.copy would
attempt to extract the new VDI reference from the task result straight
away, but import_raw_vdi did not add this to the task result on
completion, leading to the VM.copy failing with Xml.Error.

Adding the new VDI ref to the VDI.copy task result did not fix the
problem, as in this case the VM.copy operation would immediately destroy
the VDI.copy task as soon as it was marked completed. The VDI.copy
operation would then fail, as its task no longer existed, and it would
clean up by destroying the new VDI. Meanwhile the VM.copy operation would
complete without an exception being raised.

The approach taken here is to create a new task for the import_raw_vdi
operation. VDI.copy watches for this task to be completed, and VM.copy
in turn watches for the VDI.copy operation to be completed. This way
there is no race between VDI.copy and VM.copy, and the new VDI ref is
automatically added to the VDI.copy task's result on completion.

Signed-off-by: John Else <john.else@citrix.com>

Conflicts:
	ocaml/xapi/sm_fs_ops.ml
CA-127975: Add explanatory comment

Signed-off-by: John Else <john.else@citrix.com>

Conflicts:
	ocaml/xapi/sm_fs_ops.ml