Add Password Advice Support

[jzheaux]

This commit adds configuration options to .passwordManagement to allow for additional password management flows:

1. Show a default change password page and enforce configured password rules
2. Enforce configured password rules at login time; either request or require that the user change their password accordingly
3. Allow admin to force password changes

You can activate by publishing a UserDetailsPasswordManager bean and using the PasswordManagement DSL:

@Bean 
UserDetailsService users() {
    // ...
    return new InMemoryUserDetailsManager(...);
}

...
@Bean 
SecurityFilterChain securityFilters(HttpSecurity http) throws Exception {
    http
        // ...
        .passwordManagement(Customizer.withDefaults());

    return http.build();
}

Since these flows require a UserDetailsPasswordManager bean, and because .passwordManagement is a pre-existing DSL, they remain inactive until that bean is provided.

Some things to try:

• ChangePasswordAdvisor - the PR contains several sample implementations of this interface. They can be composed in DelegatingChangePasswordAdvisor to form a custom set of password requirements. By default, two advisors are active; the compromised password advisor and the password advice advisor checking for any existing advice
• ChangePasswordAdvice.Action - the existing advisors can be configured to have a different action, for example changing the failure action to Action.MUST_CHANGE instead of Action.SHOULD_CHANGE
• UserDetailsPasswordManager contains any advice tied to a user. By default, .passwordManagement only checks at login time and when a password changes. However, you can write a ChangePasswordAdviceRepository implementation that checks the UserDetailsPasswordManager on each request so that the user is advised mid-session if changes are needed.

[rwinch]

Thanks for all of your work on this! I've provided some feedback below. Much of it is related to the sample, which is why I've posted it below rather than inline:

• Try and reduce (ideally eliminate) the need for HttpServletRequest and HttpServletResponse for arguments to Spring Controllers (e.g. HomeController in the sample). This might be something required for more advanced use cases, but I'd like to try to allow users to follow best practices of not using the request/response in the controllers.
• Can you demo how to clean up the error message when changing a password? Right now the error message seems like it would be difficult for a user to understand what is going on?
• What does an application with the minimum amount of effort for a user look like (as many defaults as possible)?
• I wonder if we can remove PasswordAdvice from the UserDetails. Perhaps managing this on a PasswordAdvisor implementation?
• Does PasswordAdvisor need a UserDetails or could it use a more narrow scope (e.g. username/password)? I ask because there are likely passwords/secrets that are checked outside of the scope of a User (e.g. a consumer secret). I don't know that we need to solve for all of these use cases now, but somewhat thinking outloud. Note: If we have a rich object as an argument to PasswordAdvisor, we could consider adding an optional UserDetails later.