SecurityContextHolderStrategy bean should be copied to SecurityContextHolder by default

Now that applications can use a SecurityContextHolderStrategy bean, there's value in assisting applications with what may be a sizeable transition away from using SecurityContextHolder.

There are some cases where an application may not want to copy the SecurityContextHolderStrategy bean into SecurityContextHolder's static field:

• The application may not want to risk potential memory leaks from setting a bean to a static field
• The application uses more than one application context, each with a SecurityContextHolderStrategy. Given that arrangement, it is undefined which bean will be set to the static field.
• The application may want to discourage the use of static lookups.
• The application may otherwise need more control over deciding what goes into the static field.

Given the foundational nature of SecurityContextHolder in Spring Security, it's likely that applications for a time will want to assume the above risks. As such, this should be property-driven.

One way to do this is to introduce useSecurityContextHolder into @EnableWebSecurity. It would default to true.

If useSecurityContextHolder is true, then Spring Security will look for a SecurityContextHolderStrategy bean and call SecurityContextHolder.setSecurityContextHolderStrategy. If it's false, then no action will be taken.

Start by tracing @EnableWebSecurity configuration and the existing SecurityContextHolderStrategy bean handling, then inspect how SecurityContextHolder.setSecurityContextHolderStrategy is used. Done means a property on @EnableWebSecurity defaults to true, copies the strategy bean when enabled, and takes no action when disabled; the issue does not name specific files or tests.