This patch adds the volume retype operation, which allows a user to
change a given volume's type.
When retyping, the scheduler checks if the volume's current host can
accept the new type (i.e., it checks if the host passes the filters when
using the new type). If the current host is suitable, its manager is
called which calls upon the driver to change the volume's type.
There are two cases where a retype operation may require migrating the
volume:
1. The volume's current host cannot accept the new type
2. The volume's driver cannot perform the retype operation
In case of a migration, a volume with the new type is created, and the
data is migrated to it.
Volume migrations resulting from retype can be controlled by passing a
policy, which can be either:
1. 'never': Never migrate (the retype fails if migration is required)
(default)
2. 'on-demand': Migrate when necessary
This version will cause retype operations to fail if the current and
new volume types have different:
1. QoS settings that are enforced by the front-end for in-use volumes.
2. encryption settings.