Enable use of PathPattern for RSocket routing

[bclozel]

As of #21292, Spring Messaging supports RSocket.

The RSocketMessageHandler implementation extends MessageMappingMessageHandler, which is using an AntPathMatcher as a base for pattern matching. We know that this implementation is not the most optimized, as we have used PathPatternParser in Spring WebFlux.

Since PathPatternParser and PathPattern can be seen as general purpose utilities, should we move those from spring-web to spring-core? We could keep the current ones in place, deprecate them and make them extend the new ones in spring-core.

To be used in Spring Messaging, we'd need to add a new configuration option in PathPatternParser to change the separator, which is currently hardcoded to / - it seems this class has been designed with this possibility in mind.

[rstoyanchev]

We did state this for PathPatternParser. In retrospect however those stated benefits apply also to scenarios with runtime pattern matching to some input path, under load and a potentially long list of patterns, i.e. like the RSocket case.

For the syntax, I don't see anything that makes PathPattern married to HTTP URLs. It did make some syntax refinements compared to AntPathMatcher but those were more geared at the needs of matching to some input path at runtime as opposed to "Ant paths" where the original goal was matching to resources such as files.

For the implementation, note that such a change would also involve PathContainer which is the input type to PathPattern and currently resides in http.server. I do wonder if there is another way to achieve this for example by creating some common abstraction in spring-core with spring-web having the only implementation created for HTTP but usable for other processing scenarios too. It would mean that spring-messaging requires spring-web for pattern matching in RSocket but we already have that question for codecs with spring-web containing mots of the useful ones, e.g for json and protobuf.

[rstoyanchev]

MessageMappingMessageHandler now accepts an RouteMatcher instead of PathMatcher which can be used with a PathPattern based RouteMatcher implementation.