Add support for two OpenID Connect key-pairs

[mitchellhenke]

🛠 Summary of changes

Following up on #11612, this adds a secondary OpenID Connect key-pair that gives us the ability to do a zero downtime rotation. The two externally facing elements that require changes are:

• Our /api/openid_connect/certs route which relying parties use to verify our signed payloads (token, security events)
• Our verification of the deprecated id_token_hint parameter in OIDC Logout

Previously, we did not allow "missing" app artifacts, but we may not always have a secondary key-pair, so the class was modified to allow it (though it still defaults to not allowing it).

[zachmargolis]

LGTM.

One last thought is that maybe we could redo the naming of the primary/secondary? The existing pattern we have for PII fingerprinting, attribute encrypting, and other rotatable secrets is like is hmac_fingerprinter_key for the current one and hmac_fingerprinter_key_queue for older ones.

So my proposal here would be something like oidc_private_key and oidc_private_key_queue, then oidc_public_key and oidc_public_key_queue?

[mitchellhenke]

LGTM.

One last thought is that maybe we could redo the naming of the primary/secondary? The existing pattern we have for PII fingerprinting, attribute encrypting, and other rotatable secrets is like is hmac_fingerprinter_key for the current one and hmac_fingerprinter_key_queue for older ones.

So my proposal here would be something like oidc_private_key and oidc_private_key_queue, then oidc_public_key and oidc_public_key_queue?

Yeah, I had been hoping to find a way to do that, but I'm not sure on the past way to handle it. I added a commit to put it in the Rails application config, which feels alright? Open to suggestions though.