Check destination_type when booting with bdm provided

When booting instance with block_device_mapping provided, in the current implementation, the "destination_type" is allowed to be None, and this lead to un-sync between Nova and Cinder:

Step 1: Booting with block_device_mapping, leave destination_type to be None:

root@SZX1000191849:/var/log/nova# nova --debug boot --flavor 1 --image 2ba75018-403f-407b-864a-08564022e1f8 --nic net-id=cce1d2f1-acf4-4646-abdc-069f8d0dbb71 --block-device 'source=volume,id=9f49d5b0-3625-46a2-9ed4-d82f19949148' test_bdm

the corresponding REST call is:
DEBUG (session:342) REQ: curl -g -i -X POST http://10.229.45.17:8774/v2.1/os-volumes_boot -H "Accept: application/json" -H "User-Agent: python-novaclient" -H "OpenStack-API-Version: compute 2.37" -H "X-OpenStack-Nova-API-Version: 2.37" -H "X-Auth-Token: {SHA1}4d8c2c43338e1c4d96e08bcd1c2f3ff36de14154" -H "Content-Type: application/json" -d '{"server": {"name": "test_bdm", "imageRef": "2ba75018-403f-407b-864a-08564022e1f8", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "2ba75018-403f-407b-864a-08564022e1f8", "destination_type": "local"}, {"source_type": "volume", "uuid": "9f49d5b0-3625-46a2-9ed4-d82f19949148"}], "flavorRef": "1", "max_count": 1, "min_count": 1, "networks": [{"uuid": "cce1d2f1-acf4-4646-abdc-069f8d0dbb71"}]}}'

Step 2: After the instance is successfully launched, the detailed info is like this:

root@SZX1000191849:/var/log/nova# nova show 83d9ec32-93e0-441a-ae10-00e08b65de0b
+--------------------------------------+----------------------------------------------------------------------------------+
| Property | Value |
+--------------------------------------+----------------------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | SZX1000191849 |
| OS-EXT-SRV-ATTR:hostname | test-bdm |
| OS-EXT-SRV-ATTR:hypervisor_hostname | SZX1000191849 |
| OS-EXT-SRV-ATTR:instance_name | instance-00000016 |
| OS-EXT-SRV-ATTR:kernel_id | 87c9afd6-3a47-4a4c-a804-6b456d68136d |
| OS-EXT-SRV-ATTR:launch_index | 0 |
| OS-EXT-SRV-ATTR:ramdisk_id | acd02b28-6484-4f90-a5e7-bba7159343e1 |
| OS-EXT-SRV-ATTR:reservation_id | r-fiqwkq02 |
| OS-EXT-SRV-ATTR:root_device_name | /dev/vda |
| OS-EXT-SRV-ATTR:user_data | - |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2016-11-25T06:50:36.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| config_drive | |
| created | 2016-11-25T06:50:30Z |
| description | - |
| flavor | m1.tiny (1) |
| hostId | 410c49382deba8e205044b231169b2a656b27b6c994815366712b62e |
| host_status | UP |
| id | 83d9ec32-93e0-441a-ae10-00e08b65de0b |
| image | cirros-0.3.4-x86_64-uec (2ba75018-403f-407b-864a-08564022e1f8) |
| key_name | - |
| locked | False |
| metadata | {} |
| name | test_bdm |
| os-extended-volumes:volumes_attached | [{"id": "9f49d5b0-3625-46a2-9ed4-d82f19949148", "delete_on_termination": false}] |
| private network | 2001:db8:8000::5, 10.0.0.13 |
| progress | 0 |
| security_groups | default |
| status | ACTIVE |
| tags | [] |
| tenant_id | 405a8b8100ae47ffaa89730681ee400f |
| updated | 2016-11-25T06:50:36Z |
| user_id | 43db6c7e51754c0d8c8b87278144f789 |
+--------------------------------------+----------------------------------------------------------------------------------+

As been shown, a volume attach is recored in Nova

Step 3: Check the volume status in Cinder:

root@SZX1000191849:/var/log/nova# cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 9f49d5b0-3625-46a2-9ed4-d82f19949148 | available | - | 1 | lvmdriver-1 | false | |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+

The volume is still available.

The volume is actually not attached by checking the instance's XML.
We should forrbid the boot call with None destination_type both in Nova and NovaClient.