[3.0] External authentication (part 2 of 5) — lets members sign in with an OpenID Connect provider

[albertlast]

Do not merge without #9492. On its own this PR lets anyone holding a member's session attach a permanent new way into their account, which a password change and a logout both fail to revoke — so it removes an eviction lever the forum has today. #9492 puts a re-authentication check in front of it. See the merge order note on #9381.

Description

Feature series: external authentication, part 2 of 3. These belong together and are
not bug fixes:

part 1	#9381	groundwork: makes login reusable by something other than the password form
part 2	this PR	OpenID Connect sign in (Google, Microsoft, Keycloak, …)
part 3	to come	passkeys (WebAuthn), as a passwordless first factor and as a second factor

This branch contains part 1's commits, because GitHub cannot base a PR on a branch that
lives in a fork. Review the last commit only, or wait for #9381 to merge and this will
reduce to it. Part 3 does not depend on this one; both sit on part 1.

---

Lets a forum hand authentication to an external identity provider instead of being the only
thing that knows a member's password. An admin adds a provider, the login form grows a
button for it, and members manage their own links from their profile.

Protocol. Authorization code flow with PKCE and a confidential client. The ID token is
read from the response to our own back channel POST to the token endpoint, over TLS with the
certificate verified and the client authenticated — the case OpenID Connect Core §3.1.3.7
item 6 allows signature validation to be skipped in. That is why the certificate check in
OidcClient::fetch() is not optional and why the token is never taken from the redirect. It
keeps JWKS handling, and a hard dependency on openssl that SMF does not currently have,
out of this entirely. No new composer dependency.

iss, aud, azp, exp and nonce are all checked, state is checked against the
session and cleared on use, and the discovery document's issuer must agree with the
configured one.

Why not WebFetchApi. It cannot set request headers, which the token and userinfo
endpoints need, and makeSafe() rewrites the host to a literal IP, which defeats the
certificate check. CurlFetcher allows headers but defaults to
CURLOPT_SSL_VERIFYPEER => false, which is not something to inherit for a token exchange.
So the handful of options that matter are set explicitly instead of destabilising a fetcher
that avatars and the proxy also use.

Who a sign in belongs to — the decisions that matter more than the code:

• The provider's sub is the key. Email never is, unless an admin turns it on per provider
  and the provider says email_verified; otherwise anyone who can get an address issued
  there could walk into the account that uses it here. Off by default.
• Somebody with no account is handed to the ordinary sign up form rather than having one
  created for them, so the agreement, privacy policy, COPPA and admin approval all still
  apply. The credential is attached once that finishes.
• A member who is already signed in and returns from a provider gets it linked, not swapped.
• The last credential cannot be unlinked while it is the member's only way in.

Testing. Run against a real Keycloak on the compose network, driving the whole thing as
a browser would: the login form offers the provider; the redirect carries response_type,
client_id, state, nonce and an S256 code_challenge; the provider's own login form
authenticates; the callback exchanges the code and validates the claims. First run with no
matching account lands on the sign up form; after linking the subject to a member, the same
round trip ends logged in, through part 1's Login2::completeLogin().

Refusals were tested too, all five correct: no code or state, a state we never issued, a
code with no state, a provider-reported error, and replaying a state that was already used.
Credential::remove() refuses to take the last credential from an account with no password
and allows it once there is one. Part 1's 14-check login regression suite still passes
unchanged. Provider table verified on MySQL and PostgreSQL.

Two things caught by testing rather than review, both fixed here: Provider::__construct() merged saved settings with +, which keeps the left operand and so silently discarded
every saved setting; and the callback needed the state cleared before use to stop replay.

Issues References (Fixes|Related|Closes)

1. Part 2 of the external authentication series; builds on [3.0] External authentication (part 1 of 5) — lets something other than a password log a member in #9381