oauth2: add a generic OIDC provider type

[nagaboinaramgopal]

Description

The OAuth2 plugin resolves a login to a UserOAuth2Authenticator through a fixed
provider-name to Spring-bean map. Each OIDC vendor is its own bean
(GoogleOAuth2Provider, GithubOAuth2Provider, KeycloakOAuth2Provider) running the
same authorization-code flow with no vendor-specific logic in it. Two consequences:
adding an IdP means shipping a new class, and because provider is simultaneously the
display name and the routing key, a domain can register exactly one keycloak.

This PR decouples the two by adding a type column to oauth_provider:

• OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider looks the name up in the
  bean map first, as before, and only on a miss falls back to the registration's type.
  provider becomes an admin-chosen label; type selects the implementation. One bean
  can serve any number of registrations under arbitrary names.
• getUserOAuth2AuthenticationProvider, verifyUser and verifySecretCodeAndFetchEmail
  now carry the registration name, so a shared bean knows which row it is acting for.
• Existing google/github/keycloak rows have a null type and continue to dispatch
  by name, on the same code path as today.

GenericOIDCOAuth2Provider is registered under type=oidc and configured with the issuer
URL alone. It reads token_endpoint and jwks_uri from the issuer's
.well-known/openid-configuration (cached; the document's issuer must match the
configured value), and validates the id_token before trusting any claim in it: signature
against the JWKS key named by the token kid, then issuer, audience and expiry, via CXF's
JwsJwtCompactConsumer / JwkUtils / JwtUtils. That is cxf-rt-rs-security-jose,
already on the plugin classpath, so no new dependency.

Unlike the vendor providers, it holds no token in an instance field. The code is exchanged
per call, and a code verified through verifyOAuthCodeAndGetUser is cached for 60s and
consumed once, so the oauthlogin that immediately follows does not re-present it to the
IdP.

API / response fix: ListOAuthProvidersCmd and UpdateOAuthProviderCmd derived the
response enabled flag from authenticatorPluginNames.contains(provider), a
name-to-bean check, which reported every generically-named registration as disabled. Both
now also accept a registration whose type resolves to a plugin.

type is settable on register but not on update: changing it would swap the
implementation under an existing row.

Schema: adds type and issuer_url to oauth_provider in the 4.23.0.0 to 24.0.0
upgrade file.

UI: Login.vue renders a button per registered oidc provider (in addition to the
existing google/github/keycloak buttons), labelled "Sign in with ". Clicking it
reads the issuer's authorization_endpoint from discovery and starts the
authorization-code flow. As with the keycloak provider, the registered redirecturi must
carry verifyOauth (for example https://<ui-host>/client?verifyOauth) so the callback
lands on the verify handler.

Fixes: #9609

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Screenshots (if appropriate):

How Has This Been Tested?

Unit tests - oauth2 module, 103 tests green.

• GenericOIDCOAuth2ProviderTest (27 tests) generates an RSA keypair, publishes the
  matching JWKS, and asserts that a genuinely signed token is accepted while these are
  rejected: a token with altered claims, one signed by a different key, one naming a kid
  absent from the JWKS, and issuer / audience / expiry mismatches. Also covers discovery
  document validation (issuer mismatch) and that a verified code is redeemed exactly once.
• OAuth2AuthManagerImplTest covers the type fallback, an unknown type rejected at
  register time, and a real bean name winning without a DB lookup.
• Vendor provider tests updated for the name-carrying signatures.
• DatabaseUpgradeCheckerTest green with the new schema file.

Integration - KVM advanced zone against Keycloak 25. Registered an oidc provider
pointing at a Keycloak realm and logged a real user in through the Keycloak form:
verifyOAuthCodeAndGetUser validates the RS256 signature against the realm JWKS and
returns the email, oauthlogin with the same code issues the session, and
listOauthProviders reports the generically-named provider as enabled.

How did you try to break this feature and the system with this change?

• A login presenting a valid, correctly signed token but claiming a different CloudStack
  user's email - rejected, no session.
• Replay of an already-consumed code - rejected, no session.
• A bogus/garbage code - rejected, no session.
• After each of the above, a fresh correct login still succeeds.
• Existing google/github/keycloak registrations are untouched and still log in
  (name-based dispatch, null type).
• Discovery document whose issuer does not match the configured issuer URL - rejected.

[nagaboinaramgopal]

This is the generic OIDC provider from the discussion on #13854: one oidc type that serves any number of registrations under admin-chosen names, with discovery and full id_token validation, so a new IdP no longer needs its own class.

It overlaps #13499 (ForgeRock), which @bddvlpr put on hold in favour of doing the generic feature. My GenericOIDCOAuth2Provider is separate from the AbstractOIDCOAuth2Provider there, but three files touch the same code: RegisterOAuthProviderCmd, spring-oauth2-context.xml and Login.vue. Whichever lands second is a small rebase and I am happy for that to be mine.

@bddvlpr @Damans227 this builds on your design, so please review. If you would rather fold the ForgeRock case in here as an oidc registration, or keep it as a named provider on top, either works.