Improvements to RSocketStrategies

[bclozel]

We should try and use the PathPatternRouteMatcher as a default RouteMatcher implementation in the RSocket infrastructure if it is available (i.e. if spring-web is on the classpath).

[bclozel]

Here's a summary of the current situation:

• spring-messaging does not depend on spring-web
• spring-web provides an efficient implementation of RouteMatcher, used with Spring WebFlux: PathPatternRouteMatcher
• we'd like to use it if available in RSocket, if spring-web is on the classpath
• in the long term, we might promote the PathPattern infrastructure as a default in other places (like Spring MVC)

We could add an optional dependency from spring-messaging to spring-web, but that would break our strict module arrangement and could lead to unfortunate imports. We could still avoir those imports with custom checkstyle rules.

We could use a 100% reflection approach for this case, but one could argue that we're usually not in the business of conditional configuration for Spring dependencies (usually Spring Boot is in charge of that).

The third alternative would be to move that PathPattern infrastructure to core, but this is even more disruptive at that point.

Flagging this for team attention.

[rstoyanchev]

Team Decision: Add a small number of extensions in spring-web under org.springfamework.web.remoting.rsocket to make it possible to plug in the PathPatternRouteMatcher and codecs available in spring-web. Probably a couple of customizers for RSocketMessageHandler and RSocketStrategies.