CA-101699: Run VM.copy on the master

The VDI.copy subtask(s) created by VM.copy will be forwarded to suitable
hosts, so it's debatable whether we need to forward VM.copy at all.

Before this change the VM.copy task was forwarded based on source SR(s)
only, which is definitely wrong - in the case where a VM is being copied
from shared storage to local storage, the VM.copy task would be
forwarded to a random host (with slaves preferred) and then the VDI.copy
task(s) would be forwarded again to the host connected to the local
storage.

Besides kicking off VDI.copy tasks, VM.copy mostly just creates objects
in the database and watches for events on those VDI.copy tasks, both of
which are most efficient on the master.

Maybe when the database is split up across hosts it will make more sense
to forward the VM.copy task to a host which can see both the source and
destination SRs.

Signed-off-by: John Else <john.else@citrix.com>
CA-101699: Don't serialise VM.copy per host

VDI.copy is the CPU-intensive task so there's no need to serialise
VM.copy per host, especially now that VM.copy always runs on the master.

Signed-off-by: John Else <john.else@citrix.com>
CA-101699: Allow VDI.copy if a VDI is only attached RO

Attempting to copy a VDI which is being written to can confuse
sparse_dd, however if a disk is only attached RO it's safe to copy it.

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

This can be used as a basis for more VDI.allowed_operations tests so
let's give it a more generic name.

Signed-off-by: John Else <john.else@citrix.com>
CA-101699: Add unit tests for the allowed_operations changes

Signed-off-by: John Else <john.else@citrix.com>
Merge pull request #1187 from johnelse/ca-101699

CA-101699: Fixes for concurrent VM/VDI copy