Attaching a volume returns HTTP 202

Instead of returning an HTTP 200 and a `volumeAttachment` object,
attaching a volume to an instance returns HTTP 202 starting from API
version 2.101.

To keep the functionality for older API versions, we move the
`_attach_volume()` method from n-api to n-conductor and either do a call
or a cast depending on whether the API needs to return a value.
n-conductor then handles reserving the block_device_mapping's device by
calling n-compute before it starts the previously-already-async volume
attachment.

We have to move `_check_attach_and_reserve_volume` into compute utils,
because it's getting called in both conductor and compute api (for the
shelved offloaded attach).

The new RPC method in the conductor needs a long timeout when used with
API versions less than the new 2.101, because it waits for the call to
`reserve_block_device_name()` in nova-compute which already needs a long
timeout.

Updating the functional tests' `post_server_volume()` and
`_attach_volume()` to not return the attachment anymore is possible, as
no test uses the returned values.

Change-Id: I4d38c2679f0e88cca30055a9c8c45ba1dd6fb5ef
Implements: blueprint async-volume-attachments
Signed-off-by: Johannes Kulik <johannes.kulik@sap.com>

releasenotes/notes/bp-async-volume-attachments-b2b9cd8a4cc54b30.yaml

@@ -0,0 +1,10 @@
+---
+features:
+  - |
+    A new microversion has been added to allow fully-asynchronous attachment of
+    volumes to a server. Previously, calling ``POST
+    /servers/{server_id}/os-volume_attachments`` to attach a volume would
+    return HTTP 200 containing a ``volumeAttachment`` object, returning a
+    device name. With API version 2.101 this changes to HTTP 202. The reason
+    is, that the device name could not be assured by any of the current drivers
+    and reserving the device name could block the API thread for some time.