We check the microversion when creating a new-style volume attachment.
If we use that API and create the volume attachment, we're going to
store the attachment id on the related BlockDeviceMapping object.
Code that's updating or deleting attachments for a BDM with the
attachment_id field set assumes that 3.27 is already available since
it was when the attachment was created, and therefore we don't need
to check the version again which saves us an extra GET / call to Cinder.
We also don't support rollbacks of the Cinder API, but if that did
happen and we requested 3.27 and it wasn't available, Cinder would
return a 406 error which would result in a compute fault.
Part of blueprint cinder-new-attach-apis
Change-Id: I727fce7bbd84bcf58d7f1f91377fda35e36cbc7a
3a8a7e3fc6