Introduce Gitlab::Encryption::KeyProvider for encryption key selection logic

What does this MR do and why?

Extracted from Add multiple keys support for db_key_base (!177748 - closed).

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 !177748 (closed)).

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 gitlab-com/content-sites/handbook!10303 (merged).

Encryption

The encryption key will work as before.

Decryption

All given secrets are 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 limit the allowed keys to a single key, the same key will always be used for encryption & decryption.

References

• Related to Introduce encryption key services and support m... (#527035 - closed).
• Related to Allow the `db_key_base` secret to be rotated (#25332)
• Related to Encryption key rotation (gitlab-com/content-sites/handbook!10303 - merged)
• Related to Implement the key management system in the data... (!177838 - closed)
• Resolves [Cells 1.0] Iteration 1: Introduce encryption k... (#518636 - closed)

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.