Allow to customize OIDC token x5c certificate chain verification

[sberyozkin]

Description

If the JWT token contains an inlined X509 certificate chain which must be used to verify this token's signature then this chain is currently verified like this:

1. it is run through the Vert.x Certificate validator which checks the chain is structured correctly and all but the root certificates are signed by the next one in the chain
2. The root certificate must be present in the truststore
3. The leaf certificate must either be present in the truststore or have its common name trusted with the configured property

This is not sufficient though for complex deployments so we should let users customize it with TokenCertificateValidator (this is probably a better name than CertificateValidator as both the incoming and outgoing OIDC requests may have its own TLS level certificates which are verified at the Vert.x level)

Single TokenCertificateValidator should be enough. If it is registered then steps 1, 2 remain the same but the step 3 will look like this:

3. If the leaf certificate' common name is trusted with the configured property then confirm the match. Finish with running TokenCertificateValidator

Implementation ideas

This interface will accept a parsed chain as List<X509Certificate>, and a token in the encoded form (which if necessary, can be then analyzed like this: JsonObject claims = OidcUtils.decodeTokenContent(token);) because the public key to be extracted from this currently verified certificate chain is needed before the token is decoded and parsed.
Parsing token JsonObject claims immediately will have an extra cost for custom TokenCertificateValidator which only needs to check the certificates

[quarkus-bot]

/cc @pedroigor (oidc)

[calvernaz]

I can provide an use case for this - in cases where services are pre-register to a PKI system, so they can have access to the certificates, a potential custom validation is to make sure that the certificate included contains in the subject an universal identifier that matches the issuer of the certificate. This custom validation verifies that the token was signed by an issuer that is a legit service that belongs to the PKI system and has legit access to the cert used to sign the token.

This compound with the existing chain validation offers bigger flexibility. With a custom validation, point number 3 could be removed since implementations would choose what extra validations are required.

[sberyozkin]

Reassigning to offload it from Michal's shoulders