Consider deprecating Global Authentication

In the extreme majority of Spring Boot applications, @EnableGlobalAuthentication is turned on, either through explicit use @EnableWebSecurity or the SpringBootWebSecurityConfiguration auto-configuration.

By default, this wires a UserDetailsService or AuthenticationProvider bean into a global ProviderManager, that is used as a parent of all other managers.

This approach comes with edge-cases that are often surprising to users (gh-14663), e.g. when there is a UserDetailsService+AuthenticationProvider bean, one takes precedence. We've added some logging to help user discover their misconfigurations (gh-14711), but we have an opportunity to make things more predictable.

It is difficult to discover how username+password based authentication is configured. When looking at OAuth2LoginConfigurer, Saml2LoginConfigurer or X509Configurer, users can infer which AuthenticationProvider is required and how they can extend existing behavior (e.g. applying postProcess). It is not the case with FormLoginConfigurer or HttpBasicConfigurer. Users need to be aware that HttpSecurity has a ProviderManager, and that the ProviderManager has a parent, etc. This contrasts with the Reactive security configuration, where configuration is much more explicit.

While shared logic between SecurityFilterChains may be desirable, it may not the desired default behavior. Global authentication can also be enabled more explicitly.

Related gh-13266, gh-13270

Start by reading the @EnableGlobalAuthentication behavior, SpringBootWebSecurityConfiguration, and the OAuth2LoginConfigurer, Saml2LoginConfigurer, X509Configurer, FormLoginConfigurer, and HttpBasicConfigurer references in the issue. The payload names no files or tests and does not define acceptance criteria; done would require a settled deprecation scope and implementation plan.