Internal volume IDs

We would like volume migration to be seamless to the user, and one visible aspect when moving data from the source volume to a new destination volume is the change in volume_id.

One option is to change the 'id' of the destination to that of the source after deleting the source. However, this could be a dangerous operation. Further, if the volume is attached, Nova will try to access the destination using its original ID.

The proposal makes 3 changes to the Volumes table in the database:
1. Add extern_id (String(36)) column, which is set to id in the database migration. This will hold the ID of the volume that will be returned to the user for various outputs, and input by the user for various API calls. The id is always unique and remains the primary key. The extern_id can be non-unique while migration is in progress (both the source and destination exist).
2. Add migrating_from (String(36)) column, which is set to the ID of the source volume of a migration that is in progress. It is None by default.
3. Change 'name' to be based on extern_id.

It also requires some code changes:
1. Change API calls to display the extern_id in place of the id, and hide the id. This is fairly easy to do by changing the views.
2. Existing volume_get database call will return volumes based on the id. A new database call will be added to get a volume based on extern_id; if more than one volume exists, it will return the source volume (where migrating_from is empty).
3. Change API calls to get volumes according to extern_id (can be handled mostly by changing the 'get' function in volumes/api.py). The API layer will pass internal IDs to other components, so they will not require any changes.
4. Change all API tests to have different values for 'id' and 'extern_id', and make sure things didn't break.
5. API should hide volumes that have the 'migrating_from' field set - this is the target of an ongoing migration and shouldn't be visible to a user.