Oliver/HFX-771:CA-98944: Replaced potentially lots of db calls (one per VBD) by two big get_internal_where calls

Signed-off-by: Vincent Bernardoff <vincent.bernardoff@citrix.com>

Conflicts:

	ocaml/test/OMakefile
	ocaml/test/suite.ml
	ocaml/xapi/xapi_test_common.ml
Oliver/HFX-771: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>

Conflicts:

	ocaml/xapi/xapi_vm.ml
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>
Oliver/HFX-771: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>

Conflicts:

	ocaml/xapi/xapi_vm.ml
Merge pull request #1383 from akshayramani/Oliver/HFX-771

Oliver/HFX-771: TAMPA commits for Hotfix Oliver