Option to use a specific `RedirectStrategy` in case of a `ClientAuthorizationRequiredException` catched by the `OAuth2AuthorizationRequestRedirectFilter`

Expected Behavior

It would be useful if a Spring client with oauth2Login used as a facade for a RESTful backend could delegate to the user agent the decision of when to initiate an OAuth2 flow (and what to use for it).

In the OAuth2AuthorizationRequestRedirectFilter, if the RedirectStrategy used in case of a ClientAuthorizationRequiredException differed from the one used in the nominal case, we could configure it to return a 401, letting the user agent decide what to do in that case.

Current Behavior

OAuth2AuthorizationRequestRedirectFilter always uses the same RedirectStrategy.

Let's consider the following use case:

1. The user was successfully identified with oauth2Login
2. The Spring client saved tokens in the session
3. The user went idle for long enough for the refresh token to expire, but not his session
4. The user performs an action that requires an access token

In this situation, the refresh token flow can't succeed (expired refresh token), and an exception is thrown. The OAuth2AuthorizationRequestRedirectFilter catches this exception to redirect to the authorization endpoint.

This is problematic when the Spring client with oauth2Login is an OAuth2 BFF for a user agent that isn't intended to interact with the authorization server (displaying login forms, handling remember-me cookies, etc.). If a 401 was returned, single-page and mobile applications could use a request interceptor to initiate the authorization code flow themselves, and in the way they like. For instance, instead of following with a cross-origin request using their internal HTTP client, SPAs could initiate a new navigation (set the window.location.href), and mobile apps could open the system browser.

Context
A similar need was reported in 2019, at a time when the OAuth2 BFF pattern wasn't as widely used as it is now. The solution proposed by @jessym at that time looks more like a hack to me than a way to configure a clean security filter chain for the gateway to a RESTful API.

Start at OAuth2AuthorizationRequestRedirectFilter and its handling of ClientAuthorizationRequiredException; compare the nominal RedirectStrategy path with the exception path. Define how a separately configurable strategy should support a 401 response for the BFF use case, and add coverage for both paths.