Honor @Primary for UserDetailsService and UserDetailsPasswordService in InitializeUserDetailsBeanManagerConfigurer

[siva-sai-udaygiri]

Motivation

In scenarios where multiple UserDetailsService or UserDetailsPasswordService beans
are defined, Spring may raise NoUniqueBeanDefinitionException or select the wrong
bean without explicit resolution.

Changes

• Added @Primary to UserDetailsService and UserDetailsPasswordService beans in
  InitializeUserDetailsBeanManagerConfigurer
• Ensures deterministic bean selection

Issue Reference

Fixes gh-17902

Testing

• Added a test in InitializeUserDetailsBeanManagerConfigurerTests to validate
  resolution when multiple candidates are present
• Verified that all existing tests pass with ./gradlew check

Notes

• No breaking changes
• Consistent with Spring idioms for bean resolution

[jzheaux]

Thanks, @siva-sai-udaygirl, for the PR! I've left some feedback inline.

[jzheaux]

I believe this changes the existing semantics by calling getIfAvailable instead of getIfUnique. The ObjectProvider JavaDoc implies that it accounts for @Primary:

	/**
	 * Return an instance (possibly shared or independent) of the object
	 * managed by this factory.
	 * @return an instance of the bean, or {@code null} if not available or
	 * not unique (i.e. multiple candidates found **with none marked as primary**)
	 * @throws BeansException in case of creation errors
	 * @see #getObject()
	 */

Can you confirm with unit tests that changing to getIfAvailable is necessary to support @Primary?

[siva-sai-udaygiri]

Thanks, @jzheaux! I added unit tests to show why we need to rely on the container’s autowire-candidate resolution to honor @primary.

• With getIfUnique(...) when there are two UserDetailsService beans and one is @primary, it still returns null (multiple names), so the global AuthenticationManager isn’t configured.
• With getIfAvailable(...) it delegates to autowire-candidate selection (same as normal injection), so the @primary bean is chosen, and the AuthenticationManager is configured.

New tests:

• whenMultipleUdsAndOneResolvableCandidate_thenPrimaryIsAutoWired
• whenMultipleUdsAndNoSingleCandidate_thenSkipAutoWiring

Location: spring-security-config/src/test/java/org/springframework/security/config/annotation/authentication/configuration/InitializeUserDetailsBeanManagerConfigurerTests.java

This keeps behavior the same for the single-bean case, and for multiple beans without a single resolvable candidate we still skip auto-wiring (and log). Please take another look and let me know if you’d prefer a different approach.

[siva-sai-udaygiri]

Implemented getAutowireCandidateOrNull(...) to honor @primary.
Added unit tests covering: (a) multiple UDS with one @primary → auto-wired; (b) multiple UDS with no single candidate → skipped; (c) single UDS unchanged.
Rebased on latest main and all config checks pass locally.