PLUGINS-350 Opt-in OIDC auto-login (prompt=none)

[kathrynalpert]

Adds an opt-in openid.{provider}.autoLogin flag. With it on, an anonymous visitor who lands on the XNAT login page gets sent straight into the provider's OIDC flow with prompt=none instead of having to click "Sign in with …". In an SSO setup they're already logged into the provider for everything else, so they just end up in XNAT logged in. If they don't have a session at the provider, it comes back with login_required and we show the normal login page.

The login-screen extension issues the redirect, the PKCE provider forwards the prompt param, and the filter reads the callback.

Worth calling out:

• Off by default, opt-in per provider. Only one provider may set it (first one wins, warning logged); any other providers keep their normal "Sign in with …" buttons.
• Only fires from the login page (it's a login-screen extension) for a not-yet-logged-in visitor. A short-lived guard cookie stops an immediate re-attempt, so a signed-out visitor can't get caught in a redirect loop; once it expires a later visit tries again (which also picks up someone who has since signed in to the provider).
• The loop guard and the "was this an auto-login attempt" signal both have to survive XNAT recreating the session between Login.vm and the callback — the Turbine login page and the Spring filter don't reliably see the same HttpSession. So the guard is a short-lived first-party cookie (OPENID_AUTOLOGIN_TRIED) rather than a session attribute, and the fallback decision keys off the OIDC error code alone (login_required and the other interaction-required codes only come back from a prompt=none request). The first cut leaned on a session flag for both and got it wrong — a failed attempt showed "OpenID Connect login failed" instead of the login page, because the flag was already gone by the time the callback came back. Best evidence points to the Turbine→Spring session handoff rather than pod-hopping (sticky sessions are configured) — inferred from the flow, not confirmed by capturing session IDs.
• Requires a provider that supports prompt=none — it's standard OIDC, but not universal.
• On an open (requireLogin=false) XNAT this doesn't touch normal anonymous browsing — that's served by Index.vm, not Login.vm, so the extension never runs there.

Testing

Built and deployed to dev04, which sits behind oauth2-proxy. The edge proxy authenticates everything before XNAT sees it, so to reach Login.vm anonymously I temporarily pulled the oauth2-proxy forward-auth middleware off the XNAT ingress (and put it back after).

• Fresh incognito, no provider session → hit XNAT → bounce to the provider with prompt=none → login_required → land back on the normal login page, no error banner. This is the case the fix is about.
• Incognito with a live provider session → straight into XNAT, no button click.
• Refreshing the login page after a failed attempt doesn't loop — the guard cookie holds for its short TTL, and a later visit retries (so someone who signs into the provider in the meantime still gets picked up).

Unit tests cover the redirect decision matrix (guest vs authenticated, one-shot guard, response-already-committed, provider opt-in), the prompt forwarding, and the interaction-required error classification.