Support for the "bring your own keys" approach for Cinder

[NotTheEvilOne]

Description
===========
Cinder currently lags support the API to create a volume with a predefined (e.g. already stored in Barbican) encryption key. This feature would be useful for use cases where end-users should be enabled to store keys later on used to encrypt volumes.

Work flow would be as follow:
1. End user creates a new key and stores it in OpenStack Barbican
2. User requests a new volume with volume type "LUKS" and gives an "encryption_reference_key_id" (or just "key_id").
3. Internally the key is copied (like in volume_utils.clone_encryption_key_()) and a new "encryption_key_id".

[NotTheEvilOne (ntoe)]

We've drafted a basic approach what we think needs to be changed. [1]

Here's the summary:
- Update /cinder/volume/api.py to accept an encryption key ID. The encryption key should be stored in the configured KeyManager (usually Barbican) beforehand to keep changes minimal and maintainable. Based on feedback of the OpenStack community an alternative would be to provide and store the key right away on create.
- clone_encryption_key() of /cinder/volume/volume_utils.py must be used to ensure keys can be deleted when the volume is deleted.

[1] https://input.scs.community/9FbrLgYbT8KFvZGXLzay6Q?view#OpenStack

[sean mooney (sean-k-mooney)]

for cinder this would likely require a spec as its an api change to be able to pass the barbican secrete i belive.

for nova this might be a specless blueprint if the changes were minor enough and we coudl capture the details in the cinder spec otherwisse we would need a spec for nova as well.

in either case this is not a bug in the scope of nova so ill make the nova part as invild form a paper work prespective since this would be tracked as a nova blueprint in lancuchpad with or without a spec not as a bug.