Check for non-default volume name template.

The iscsi delete methods in iscsi.py had hard-coded volume names
'volume-%s'.

If a user configured volume_name_template to
something other than default the result is failure to remove
the iscsi_target.

volume create worked appropriately and created the correct name
in the DB, so the persistence files were the only thing affected
or named incorrectly.

Fixes bug: 1101071

Change-Id: Id5575874b2cebd9b3509d739cb92abf06c503c4e
Allow volume back-end to report 'infinite' or 'unknown' as capacity

For some reason, some volume back-ends cannot report actual capacity
that is available or even total capacity (e.g. thin-provisioning),
Cinder should allow such capability report and make placement/schedule
decision based on these status.

In particular, we agree to use 'infinite' to mark unlimited space and
'unknown' to mark unknown/unclear space.  Host manager and CapacityFilter
are updated accordingly to allow such capacity.  For those back-ends
report 'infinite' or 'unknown' capacity, CapacityFilter will let them
pass to give them a chance to try.  Even if failure happened, the retry
mechanism should take care of the case.

Change-Id: I6871a28745111b1878a606372e6edd664f0ea10c
Set source volume to "in use" during clone

When we are cloning a volume, we now set the source volume's status
to 'in use'. This prevents a user from deleting the source volume while the
backend copies/clones the contents to the new volume.
When the cloning is complete, we reset the status to it's original
state.

Change-Id: Ie43345aba77df4671ed2b429645cf8d1af9b975b
Merge "Check for non-default volume name template."
Merge "Allow volume back-end to report 'infinite' or 'unknown' as capacity"
Merge "Set source volume to "in use" during clone"