Refactoring of create_volume to use taskflow.

Refactoring of create_volume to use taskflow.

Move the create_volume workflow to using taskflow and
split that workflow into three major pieces (each with
there own workflow) and create tasks that perform the
individual required actions to accomplish the pieces
desired outcome.

1. An api workflow composed of the following tasks:
  - Extracting volume request (which checks types, values) and creates a
    standard output for other tasks to work on (allowing further tasks to be
    plugged in the chain without having to worry about other tasks output
    formats).
  - Quota reservation (rolled back on failure).
  - Database entry creation.
  - Quota committing.
  - Volume RPC casting to volume scheduler or to targeted volume manager.
2. A scheduler workflow composed of the following tasks:
  - Extracting scheduler request specification for further tasks to use.
  - Change status & notify (activated only on failure).
  - Create volume scheduler driver call (which will itself RPC cast to a
    targeted volume manager).
3. A manager workflow composed of the following tasks:
  - Extract volume request specification from incoming request for
    further tasks to use. This also breaks up the incoming request into the 4
    volume types that can be created later.
  - Change status & notify on failure or reschedule on failure, this is
    dependent on if rescheduling is enabled *and* which exception types are
    thrown from the volume creation code.
  - Create volume from specification
    - This contains the code to create from image, create raw volume, create
      from source volume, create from snapshot using the extracted volume
      specification.
  - Change status & notify success.

Key benefits:
  - Handled exceptions in a easier to understand, easier to review and more
    reliable way than they are currently being handled.
  - Rescheduling is now easier to understand.
  - Easier to understand structure with tasks that consume inputs, take some
    action on them and produce outputs and revert on subsequent failure using
    whatever they produced to know how to revert.
  - Ability to add new unit tests that can test individual task actions by
    providing mock task inputs and validating expected task outputs.

Future additions:
  - Eventual addition of resumption logic to recover from operations stopped
    halfway through.
  - Ability to centrally orchestrate the tasks and pick and choice how
    reconciliation of failures based on code or policies.

Part of bp: cinder-state-machine

Change-Id: I96b688511b35014a8c006e4d30b875dcaf409d93