Duplication Checking Inconsistencies in ClientRegistrationRepository & UserDetailsService

While clearly different APIs ClientRegistrationRepository and UserDetailsService have similar natures in that they take in a likely unique identifier and lookup a record by that identifier.

ClientRegistrationRepository takes a registration id and returns a ClientRegistration
UserDetailsService takes a username and returns a UserDetails

InMemoryClientRegistrationRepository as well as InMemoryReactiveClientRegistrationRepository both check for duplicates when a list of client registrations is supplied. This is sensible since registration id is semantically a primary key - to have duplicates would be an error.

MapReactiveUserDetailsService and InMemoryUserDetailsManager do not check for duplicates though.

This is inconsistent as username is just as unique as a registration id.

This may be tricky to resolve since InMemoryUserDetailsManager is quite old and it's obvious that there may be applications that rely on the duplicate users being silently resolved through overriding.

Still, this states it for the record so that we can come back to it as opportunities come to light.

Compare InMemoryClientRegistrationRepository, InMemoryReactiveClientRegistrationRepository, MapReactiveUserDetailsService, and InMemoryUserDetailsManager to document their duplicate-handling behavior. Before changing anything, establish the compatibility expectations for existing applications; done would require an agreed policy and corresponding test coverage.