Bug 1889443

Description of problem:

Currently, it's possible for deployers to unintentionally lock all users out of their credential data.

Keystone supports a credentials backend, which is primarily used for storing MFA secrets and ec2 credentials (not passwords). In the Newton release, these credentials were encrypted so they weren't stored in plaintext. The upstream community re-used the existing token enryption
mechanism to encrypt credential data. As a result, credential encryption uses an entirely separate key repository from token encryption, but both repositories are managed using similar rotation flows.

The credential backend stores a hash of the key used to encrypt it. The `keystone-manage credential_rotate` command relies on this information to ensure it doesn't overrotate the keys. If keys are overrotated, the encrypted data is unrecoverable. Deployers must use the following flow to rotate credential fernet keys safely:

1.) setup the credential repository (`keystone-manage credential_setup`)
2.) rotate the credential keys (`keystone-manage credential_rotate`)
3.) re-enrypt credentials using the newest fernet key (`keystone-manage credential_migrate`)

Steps #2 and #3 can be done as many times as needed, so long as they're done in lock-step.

Currently, we don't have anything in TripleO that enforces this workflow. It's possible for deployers to set KeystoneCredential0 and KeystoneCredential1 to keys of their own choosing, manually rotating the keys. This can result in the deployer unintentionally locking all credential data since the symmetric keys used to encrypt them are no longer available.