Avoid eager PasswordEncoder initialization in ClientSecretAuthenticationProvider

[alexey-anufriev]

ClientSecretAuthenticationProvider eagerly initializes its default PasswordEncoder using PasswordEncoderFactories.createDelegatingPasswordEncoder()
in its constructor.

spring-security/oauth2/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/authentication/ClientSecretAuthenticationProvider.java

Line 79 in 3d23cf3

this.passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();

This factory creates legacy MessageDigestPasswordEncoder instances, including MD5. On a FIPS-compliant JDK where MD5 is unavailable, constructing ClientSecretAuthenticationProvider fails even
when a custom FIPS-compatible PasswordEncoder is configured.

spring-security/crypto/src/main/java/org/springframework/security/crypto/factory/PasswordEncoderFactories.java

Line 78 in 3d23cf3

encoders.put("MD5", new org.springframework.security.crypto.password.MessageDigestPasswordEncoder("MD5"));

This is similar to the issue discussed in gh-14670.

DaoAuthenticationProvider already avoids this problem by lazily initializing its default PasswordEncoder using SingletonSupplier.

spring-security/core/src/main/java/org/springframework/security/authentication/dao/DaoAuthenticationProvider.java

Line 58 in 3d23cf3

private Supplier<PasswordEncoder> passwordEncoder = SingletonSupplier

I would like to suggest to apply the same pattern to ClientSecretAuthenticationProvider, preserving the existing public API and default behavior while avoiding construction of the default encoder
when setPasswordEncoder() is used.

I would be happy to submit a PR if this approach sounds correct.