core, restapi: Introducing support for attaching disk snapshot

This patch adds the engine support for attaching a disk snapshot to a
VM (currently different VM than the one for which the VM
snapshot was taken).

Before this change, when attaching a disk to a vm only the active volume
was used, if the user wanted to see the disk content at some snapshot he
had to preview that snapshot.
After this change, a snapshot of a disk can be attached to another vm,
regardless of the disk not being marked as shareable - when doing so,
VDSM should create a temp snapshot allowing read/write access above the selected snapshot,
the above should happen when hotplugging a disk/ running a vm.

The following limitations currently applies on that ability:
1. The created temp snapshots is stored on the host local storage (the host that the vm is running on)
and not on the shared storage (domains) therefore the vm can't be migrated.
2. A disk snapshot can be attached to a different VM than the one of
which the snapshot (VM snapshot) was taken of.

Usage:
1. Navigate to the wanted disk snapshot from REST by accessing:
SERVER:PORT:/api/vms/GUID/snapshots/GUID/disks

2. POST the copied disk XML to:
http://SERVER:PORT/api/vms/GUID/disks/

Patch with lock handling is dependent on this one to ease the review.

OPEN ISSUES:
UI  - would be handled in a following patch (the
information is accessible through REST)

Change-Id: I02579bf1a91cd294a5040acf432f1fdb87eb18c1
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: adding support for db lock of all disk snapshots

This change is part of http://gerrit.ovirt.org/#/c/17679/ and is
separated just for review sake.

This patch adds the ability to lock all disk snapshots/volumes as part
of adding support for attaching disk snapshots to VMs.

The added method in ImagesHandler can be used to lock all the disk
snapshots, while the current "lock" method locks the given volume only.
The need for this change is to prevent race conditions, provide
ability to lock only the needed snapshots of a disk and to have correct
UI indication of the current state.

Example use cases:
1. When removing a disk, all the disk snapshots should be locked and
have their status reverted (otherwise they will be displayed as "OK" for
vms that they are attached to).
2. When extending a disk with snapshots, only the active snapshot should
be locked as other snapshots can be used as attached disk snapshots in
other vms.
3. When moving a disk all the disk snapshots should be locked, as when
the copy of the data ends the source would be deleted.

Change-Id: Ibac8daf6a9e970859a6759d84d7849e7f84e0d79
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: lock correct volume when creating a template

When creating a template out of a vm, CreateImageTemplateCommand is
being called for each of the needed vm disks. In that command there all the
disk snapshots are being loaded in order to lock the active disk
snapshot.

That logic caused for 2 bugs in that command:
1. The lock is done always on a wrong disk snapshot, as
ImagesHandler.getAllImageSnapshots() will always return the active
images as first on the list, and ImagesHandler.getActiveVolume() returns
the last on the list, the lock won't be performed on the active volume.

2. The cloned disk properties were copied from that snapshots and from
the correct snapshots, leading to wrong persisted information.

The fix is to just remove that load and set, as currently a template is
created for the active disks only we are supposed to always have the
active one already loaded.

If and when creating a template from a snapshot will be supported, the
locking could be re-inspected, right now there's no need for further db
loads.

Change-Id: I7f27535de8ec6e007035ffa7a2e5fad80460701a
Signed-off-by: Liron Aravot <laravot@redhat.com>