[Cells 1.0] Iteration 1: Introduce encryption key services
The is MR introduces a `Gitlab::Encryption::KeyProvider` class that acts as a builder class for key providers given a key type. The returned key provider wrapper responds to `#encryption_key` and `#decryption_keys`, similarly to `ActiveRecord::Encryption::KeyProvider`. The services allows to hide the details about what actual secrets are passed to each key provider. We're relying on `ActiveRecord::Encryption`'s native providers:
* `Gitlab::Encryption::NonDerivedKeyProvider` a thin sub-class of `ActiveRecord::Encryption::KeyProvider` to wrap given secrets in `ActiveRecord::Encryption::Key`
* `ActiveRecord::Encryption::DerivedSecretKeyProvider`
The goal is to use `Gitlab::Encryption::KeyProvider` to get the encryption/decryption key(s) in all the places where we would fetch the key directly from `Settings` before, but this will be done iteratively through several MRs to reduce the scope of change and required approvals (which was a problem with https://gitlab.com/gitlab-org/gitlab/-/merge_requests/177748).
This also adds support for defining `db_key_base` as an array instead of a single key to be on-par with how Active Record Encryption allows to define multiple keys.
The `db_key_base` secret is now wrapped in an array even if it's a single string. For now, actually defining an array of keys will raise an error because we first need to record what key was used to encrypt data before we can actually support multiple keys (so that we can know what data needs to be re-encrypted when a new key is introduced). For more details, see the proposal at https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/10303.
### Encryption
The encryption key will always be the last value in the array.
### Decryption
All `db_key_base` secrets will be used in turn until one can decrypt the encrypted value, starting from the first (i.e. oldest) element to last (i.e. newest). In practice, since we always use the first key to encrypt (and since we limit to one key), it should also be the key used for decryption.
## References
**Please include **[**cross links**](https://handbook.gitlab.com/handbook/communication/#start-with-a-merge-request:~:text=Cross%20link%20issues,alternate%20if%20duplicate.)** to any resources that are relevant to this MR**. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.
* Related to https://gitlab.com/gitlab-org/gitlab/-/issues/25332+
* Related to https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/10303+
* Related to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/177838+
* Resolves https://gitlab.com/gitlab-org/gitlab/-/issues/518636+
epic