Add DestinationPathPatternMessageMatcher

[pat-mccusker]

Closes gh-16500

I wasn't sure that this configuration was safe to remove so I wanted to point it out. In WebSocketMessageBrokerSecurityConfigurationTests an AntPathMatcher is configured with a '.' path separator, and this test will fail if the mentioned config is simply removed. If consumers of spring-security are configuring a PathMatcher in a SimpAnnotationMethodMessageHandler instance, then this matching would cease to function correctly as far as I can tell.

This led me to delegating the destination pattern matching to one or another PathPatternRouteMatchers depending on which path separator is configured by the MessageMatcherDelegatingAuthorizationManager.Builder, but I've left the original builder configuration in place for the moment.

[pat-mccusker]

Hi @jzheaux, not sure if there are notifications on Draft PRs but I wanted to get your thoughts on how things looked in here so far.

[jzheaux]

Thanks for the draft, @pat-mccusker, this is a great start.

As far as your question about the prototype bean method, we should have an opt-in strategy that says that an application wants to start using DestinationPathPatternMessageMatcher instead of PathMatcher.

I think you can follow the pattern in PathPatternRequestMatcherBuilderFactoryBean. This is a factory bean that publishes a PathPatternRequestMatcher.Builder instances that applications and the DSL can use to build request matchers.

If you introduced DestinationPathPatternMessageMatcherBuilderFactoryBean, then you could do the same here, e.g. "if DestinationPathPatternMessageMatcher.Builder bean exists, then I use that to construct request matchers instead of working with path matcher"

[pat-mccusker]

I've addressed some of the more straightforward items involving the PathPatternMessageMatcher itself and will keep working on the rest.

[jzheaux]

Thanks, @pat-mccusker! I added a polish commit that brings the logic and documentation further into alignment with the request matcher changes.

Also, some of the logic in the request matcher changes was there to support the additional complexity of the configurable Spring MVC matcher. Because that isn't present here, I was able to remove some of the logic.

[jzheaux]

Thanks, @pat-mccusker, for all your work here. This is now merged into main.

[pat-mccusker]

Awesome, thanks @jzheaux for all the direction and prior examples!