Support transferring encrypted volumes

Currently, cinder does not support transferring an encrypted volume due to the need to transfer its (and its snapshots) encryption key. This blueprint proposes an enhancement to transfer the key along with the volume and its snapshots.

The mechanism relies on the ability to create a copy of an encryption key, and store it as a barbican secret that is owned by another entity. The process would work like this:

1. User X initiates the transfer

- Using the X's context, fetch the key using the volume's encryption_key_id
- Using cinder's service credentials, create a new barbican secret with the same key (i.e. the actual secret)
- Update the volume (and its snapshots) DB to store the new encryption_key_id that is owned by the cinder service
- Using X's context, delete the original barbican secret (the original encryption_key_id)

2. User Y accepts the transfer

- Fetch the key for the encryption_key_id using cinder's service credentials
- Create a copy of the key, and store it using Y's context
- Update the volume (and its snapshots) DB to store Y's new encryption_key_id
- Use the cinder service credentials to delete the barbican secret that it previously created

3. User X deletes (cancels) the transfer

Conceptually this is identical to accepting a transfer, except the recipient is X. A new encryption_key_id is generated that is owned by X, and the intermediate one owned by the cinder service is deleted.

A new microversion would be created for the feature, but otherwise there would be NO change to the volume-transfer API requests or responses.