Consider Simplifying DSL support for Spring MVC endpoints

For an application to direct Spring Security to use MvcRequestMatcher, it is necessary to use requestMatchers(RequestMatcher...), requiring each request matcher to be constructed by hand.

It may be handy to add authorizeMvcRequests as a convenience method to reduce that boilerplate.

For example, instead of doing:

http
    .authorizeHttpRequests((authorize) -> authorize
        .requestMatchers(new MvcRequestMatcher.Builder(introspector).servletPath("/my-servlet").pattern("/**")).hasAuthority("USER")
        .requestMatchers(new MvcRequestMatcher.Builder(introspector).pattern("/endpoint/**")).hasAuthority("USER")
    )

an application could do the following:

http
    .authorizeMvcRequests("/my-servlet", (authorize) -> authorize
        .anyRequest().hasAuthority("USER")
    )
    .authorizeMvcRequests((authorize) -> authorize
        .requestMatchers("/endpoint/**").hasAuthority("USER")
    )

In this case, the request matcher registry used would be one that would only have requestMatchers(String...), requestMatchers(HttpMethod), requestMatchers(HttpMethod, String...), and anyRequest(). When the servlet path is supplied, anyRequest() would be scoped to that servlet.

The nice thing about this is it encourages applications that have more than just Spring MVC to separate the rules by servlet path, which is a bit more harmonious with how MvcRequestMatcher performs its pattern matching.

There may be more straightforward ways for an application to describe its intent, and this is a good place to share those.

Start with the requestMatchers, authorizeHttpRequests, and MvcRequestMatcher.Builder usage shown in the issue, then review how the matcher registry handles servlet paths. Determine whether an authorizeMvcRequests convenience API and servlet-scoped anyRequest express the intended configuration; the work is done when the API design and behavior are settled.