…migration

Live migration with storage into a Linstor pool spawned the destination
resource through the resource group's auto-placement, which knows nothing
about the target host. PrepareForMigrationCommand still describes the source
disks, so the target agent never connected the new volume either. If the
placement left the target host without a copy (place count 1, no quorum
tiebreaker, 4+ nodes with 2 copies, node filters), the block device was
missing there and libvirt aborted with
"cannot precreate storage for disk type 'block'".

Make the resource available on the target host right after creating it and
take the device path from there. The source is not a Linstor resource of
this pool, so no dual-primary is needed.

A failure before the migration command (creating the resource,
make-available, prepare for migration) now also removes the already created
destination volumes; they used to be left behind. Once the migration
command is sent, the destination volumes are only removed if the source
host reports a failure. If the command times out, the VM may still end up
on the new volumes: like StorageSystemDataMotionStrategy, check whether it
runs on the target host and finish the migration in that case, otherwise
keep the volumes. The error message names the destination pools instead of
the source host.

Unit tests cover make-available before the migration with the device path
from the target host, the cleanup when creating the resource,
make-available, prepare for migration or the migration itself fails, and a
migration timeout with and without the VM running on the target host.