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>
CA-127975: Add explanatory comment

Signed-off-by: John Else <john.else@citrix.com>
Add explicit Prototyped API lifecycle transition

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Update HTML API docs to take into account new lifecycle info

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Merge pull request #1642 from johnelse/ca-127975-clearwater-sp1

CA-127975: Run sparse_dd with new subtask during cross-host VDI.copy
Update HTML API doc branding

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Merge pull request #1644 from robhoes/prototyped-cw

Add explicit Prototyped API lifecycle transition
CA-122467: Fix for setting the right value of memory_actual after vm is started

There is a race condition between vm_start and monitor thread.
The monitor thread runs every 5s and updates the memory changes of the
VMs if any. It does that only if the VM's resident_on value is set to
localhost.
Currently, the memory changes are being seen by monitor thread while
VM is starting but since the start operation has'nt yet set the
resident_on, the monitor thread doesn't do anything.
However, the in-memory cache of monitor thread already has the vm_memory
changes for that VM. This needs to be removed, so that monitor thread
updates it next time when the resident_on value of the VM is set by
start operation.
Signed-off-by: Ravi Pandey <ravi.pandey@citrix.com>
Merge pull request #1645 from zli/xenserver/clearwater-sp1-lcm/CA-127973

[HFX Fox] CA-127973