JWT: support both certs and raw public keys

[maxtropets]

For instance, FB openid conf:
https://www.facebook.com/.well-known/oauth/openid/jwks/

Format:

        {
            "kid": "dcd214c095176e06454dfe832254b0cde52b6052",
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "n": "6GkDCgRsMiCb2Zsjge86oXAFwvRIOTEAlLCtxtFzsb2x6alKYa1ycSEmiwj_hlGXUQnbrj8VEWkT9ZigNC-WAGxhCe-RikzkmUG99_xACWzoI9zUN50Qj6jZM8-P-pmoYEnKK_7yj2gJSlzMtWYBRzJihz5-zN3Ed75GVQOuANytYbAclPmhm2-g-gfH9g6JRqYsBY6k-MMP0d5VLk8u_nAg6jf0Kw4Ii-PndlNHsyG6aXHXteyFsZ7bBOjb_nUs9C0xgiJPVqMoOtMRhelDLuj4W4N7CQVxoCEvkW6g0932eCOzteOvbawXutx18kF2bGrSgFvIOLCbnzL8dgf7zw",
            "e": "AQAB"
        },

CCF now only supports x5c field though. It has to support both x5c and n + e combination.

• Construct public key from n + e fields
• Save raw public key first OR x5c in jwt_management.h
• Raw key verification impl (currently OpenSSL_Verifier only supports certs)
• Use public key first in jwt_auth.cpp, fallback to cert if needed
• Test-cover public key verifier (unit tests)
• Test-cover third-party key provider (e2e)

[maxtropets]

@achamayou, one design question so far, shall we

• create a self-endorsed certificate and keep it in the existing schema
• OR extend the table to contain pubkeys too
• OR replace all certs with pubkeys?

Self-endorsed cert looks, as we may set expiry date explicitly, however, it may look a little weird. On the other hand, it's a smaller change, no schema changes involved.

[maxtropets]

Talked on-site. Decided to move on with extending

  struct OpenIDJWKMetadata
  {
    Cert cert;
    JwtIssuer issuer;
    std::optional<JwtIssuer> constraint;
    // new key: raw public_key
  };

This avoid breaking old entries format and simplifies transition to the new code version.