OIDC: Cluster-wide key and salt for cookie encryption

[markylaing]

When performing the authorization code flow two cookies are encrypted and stored on the client. After authentication, when the client is redirected to LXDs /oidc/callback endpoint, the receiving LXD cluster member must be able to decrypt these cookies to complete the PKCE part of the authentication flow.

It is possible that, if LXD is deployed behind a load-balancer or DNS SRV records are used, the redirection to /oidc/callback will reach a different cluster member to the one that started the login flow. Currently, the encryption keys used for these cookies are cluster member specific. If the call to /oidc/login starts on one cluster member, but the call to /oidc/callback reaches another cluster member, then decryption of these cookies fails and the authentication flow must be restarted.

This is documented in #13644

This PR adds the concept of a cluster wide secret key and salt. Both the key and the salt are stored in the config table but are hidden from the server configuration.

The key and salt have the following formats:

• salt: a ULID with the time set to the time of expiry and with (crypto/rand).Reader as the source of entropy (rather than the default monotonic reader).
• key: a 512 bytes read from (crypto/rand).Reader. In the database, this is base64 encoded and prepended with the expiry time in unix milliseconds (UTC) (delimited by a ., which base64 cannot contain).

Note that the key is not a private TLS key. It's only use is as a source for HKDF derivation of hash and block keys for cookie encryption.

Whenever the salt or key are used, the caller should check if they are still valid. If they are not valid, the caller should check if another cluster member has created a valid key/salt and stored it in the database. If the key/salt in the database is not valid, the caller should set a new one. The lxd/db/secret package has been added to handle this.

Two new configuration keys are added to manage the lifetime of the secret key (core.secret_key_lifetime default 30 (days)) and salt (core.salt_lifetime default 60 (minutes)). When the key or salt lifetime is updated, the existing key and salt are invalidated. Additionally, when a daemon joins a cluster, any secrets it is holding in memory are invalidated.

To preserve the authorization code flow in case of salt or key rotation occurring while a user is logging in, the OIDC verifier keeps old relying party configuration available in memory for 5 minutes. The verifier determines which RP to use to complete the flow by checking that it is able to decode the state cookie (which is set as part of the flow).

This PR removes dependence on the cluster private key for derivation of unique cookie encryption keys for OIDC ID and access tokens. Instead we use the cluster-wide secret key, plus the session ID, to derive unique keys per user session.

Lastly, options for instantiating a new OIDC verifier have been expanded to pass in a "host" and a context. This means that the verifier will attempt to perform discovery when the configuration is set.

Closes #13644.

Marking as draft because this is really a collection of ideas and there is no spec. If we like the approach and decide to merge, beware that this will log out all OIDC users (though if they're still logged in at the IdP, the be re-logged into LXD after a brief redirect).