For T348388: Use central login wiki for login (SUL3), we want to move login to the central login wiki:

• If you are on the login wiki, login and signup works as before (to a first approximation; changes to it are out of scope for this task).
• If you are not on the login wiki, and click on login or signup, you'll be redirected to the loginwiki login / signup page, and a successful login / signup on loginwiki will also log you in locally.

On a low level, there are at least two fairly different implementation options (see T348388#9440040 and subsequent comments). The one we probably want is:

• By default, suppress CentralAuthPrimaryAuthenticationProvider when not on the central login wiki (prevent it from returning anything on login / signup in getAuthenticationRequests()). Put this change behind a feature flag controlled by a query parameter. (Initially for QA, staged rollout etc; in the longer term as a fallback for people who run into some problem with the new login system.)
• Create a new primary authentication provider which is active when not on the central login wiki, and just redirects to central login. It shouldn't support signup, just login (on the loginwiki side, the user will be able to switch between the two flows) - the signup flow ends with the creation of a central account, but that would already have happened on the loginwiki side. T362713: Implement the new login process which redirects to the central login wiki for showing the login/signup form
• Make sure that relevant checks (block, AbuseFilter etc) still run on the local wiki to the extent it is feasible.
  • For pre-authentication providers this should just work (the only edge case I can think of that we'd have to fix is that global throttling counters would increment twice).
  • Secondary authentication providers are more tricky, but I don't think there's much use case for non-global secondary authentication providers so we probably just need to audit those.
  • For AuthManager::canCreateAccount() checks, loginwiki should probably probably proxy the call back to the origin wiki so that local username policies can be applied. T363411: Run cancreateaccount checks in the context of another wiki
• At the end of a loginwiki login or signup, loginwiki needs to communicate the results (whether it was a login or a signup, whether it was successful, the username or error message - although not sure it makes sense to end the flow unless it was successful) and redirect back. The security requirements for this might be tricky (comparable to Special:CentralLogin and Special:CentralAutologin) and will require a careful audit (see T363699: Determine SUL 3 login handshake mechanism), but that can be split off into a separate task, with the POC version just using a URL parameter or whatever. The local side would then finish the login accordingly.
  • If this was a signup, locally we probably still need to treat it as a login (otherwise we'd have to rework a bunch of things in how CentralAuth handles signups) but we need to trigger post-signup hooks somehow. Also a bunch of things depend on the autologin flag of LocalUserCreated and we need to figure out a migration path for that.

We'll still need to talk with Security, anti-abuse volunteers and some extension maintainers and make sure it's an acceptable path, so no need to come up with something 100% polished, but we should have a POC implementation to validate the idea.

One aspect that needs to be figured out is how to persist information across failed login attempts. AuthManager terminates its internal session with a FAIL response, but we need to preserve whatever information from the local wiki we are passing through the login process (probably some sort of reference to the local session, to protect against session fixation type attacks?) if the user only enters their password correctly on the second attempt, or even switches between login and signup. (Or maybe we don't actually have anything that needs preserving and so this is not an issue?)