`RefreshTokenOAuth2AuthorizedClientProvider` initialization slows down application startup

Describe the bug

During application startup RefreshTokenOAuth2AuthorizedClientProvider is created by org.springframework.security.config.annotation.web.configuration.OAuth2ClientConfiguration.OAuth2AuthorizedClientManagerRegistrar#getRefreshTokenAuthorizedClientProvider

and because of

https://github.com/spring-projects/spring-security/blob/9161eced5ba4b65d18fc0585fdf0e29b9f670235/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/RefreshTokenOAuth2AuthorizedClientProvider.java#L53

it requires quite some time (300ms; ~3% of my application startup time is spent there) to initialize because it creates a HttpClient:

Currently it's not possible in any way to disable this behavior because

• There is no constructor of RefreshTokenOAuth2AuthorizedClientProvider that leaves accessTokenResponseClient empty
• The classes can't be overriden/proxied because they are all declared final
  • I'm not sure why this is the case because OAuth2AuthorizedClientManagerRegistrar#getAuthorizedClientProviderByType checks for subclasses of this type which is impossible when they have been declared final

To Reproduce
N/A see code above

Expected behavior

• Create a constructor of RefreshTokenOAuth2AuthorizedClientProvider that does not initialize accessTokenResponseClient
• Make RefreshTokenOAuth2AuthorizedClientProvider not final so that users can provide their custom implementations. This should be done for all classes that implement OAuth2AuthorizedClientProvider
• Maybe initialize the default RestClientRefreshTokenTokenResponseClient on a background thread if available to not slow down the application start

Sample

Already described above

Start with OAuth2ClientConfiguration.OAuth2AuthorizedClientManagerRegistrar#getRefreshTokenAuthorizedClientProvider and RefreshTokenOAuth2AuthorizedClientProvider.java at the linked initialization line. Trace which OAuth2AuthorizedClientProvider implementations and constructors are created during startup, then use the existing startup reproduction to verify that the chosen change avoids unnecessary initialization while preserving refresh-token behavior.