Migration types redefine and refactor.

Currently, there are 4 types of migration in Nova: migration, live-migration, resize, evacuation.

But the definition of these types is not clear enough for viewers in different levels.

Let's see Nova as a 3-level architecture: client (novaclient) | service (conductor/compute) | driver (libvirt/xen/...). Someone may get confused in the following problems:

1. Definition of evacuation is not clear.
1) In client level :
We have "evacuate" (rebuild) and "evacuate-live" (live-migration) commmands. So evacuation == rebuild + live-migration.

2) In service level :
The evacuate() API just calls rebuild process. So evacuation == rebuild, which is different from above.

3) In driver level :
Drivers cannot see anything like evacuation. What should evacuation do ?

2. Definition of resize is not clear. Why should resize be a migration type ?
1) In client level :
The word "resize" means anything but "migration" to users. If a user just wants to resize the instance's memory size, CPU number, disk size, why should we migrate it to another node ?

2) In service level :
OpenStack is now supporting resize a VM to another compute node, reusing migration code. By setting "allow_resize_to_same-host", it also supports local resizing. This implementation is odd. If user only want to resize memory/CPU, we can use memory/CPU hotplug (which is now supported by the linux kernel, but not very well by qemu and libvirt) without shuting down the instance. Resizing primary disk may result in a rebuild.

3) In driver level :
Resize and migration are totally different things.

3. Definition of migration is not clear. Does it mean cold-migration ?

So, the 4 types: migration, live-migration, resize, evacuation, their concepts are crossing each other.

There is also another BP that was trying to split live-migration process into 3 detailed types, based on the storage type the instance is using.
(https://review.openstack.org/#/c/225910/)
But I think this is in the driver level. May be not. If my understanding is incorrect, please correct me.

So, I think the migration type should be a multi-level thing. I'd like to refact it as below:

1. Take out everything that has nothing to do with migration: resize, rebuild. Maybe "resize to another node" has some use cases. Let's talk about it.

2. In client level, depending on user's needs, provide evacuation, resize functionalities.

3. In service level, there should be only two types of migration: live and cold.

4. In driver level, split live and cold into more detailed types, maybe.