Provide a way to modify RequestMappingInfo conditions

[philwebb]

Spring Data Rest needs to take a RequestMappingInfo and modify the produces condition. It's currently not possible to do this because the required constructor is private.

I think that constructor either needs to be public, or we need some with... methods that return new instances with updated values (similar to addCustomCondition.

[philwebb]

Relates to #26415

[rstoyanchev]

RequestMappingInfo has a builder which is why the public constructors are deprecated. We can add a .mutate() instance method on RequestMappingInfo that gives a Builder pre-populated with the content of the instance. Does that sound okay? What exactly needs to be changed on the produces condition, perhaps we can tailor the Builder even better to that somehow?

[philwebb]

We probably need some input from @odrotbohm. Currently the system looks quite flexible, it takes the ProducesRequestCondition and calls a protected method that can adapt it. You can see the code in BasePathAwareHandlerMapping.

We can add a .mutate() instance method on RequestMappingInfo that gives a Builder pre-populated with the content of the instance

That might be an option, but there's currently no builder methods that take the ProducesRequestCondition objects. There's only produces(String... produces).

[rstoyanchev]

There is an issue in the referenced code since the RequestMapingInfo may have a PathPatternsRequestCondition instead of a PatternsRequestCondition. I'll add a .mutate() method on RequestMappingInfo to support the use case of changing it.

[philwebb]

Unfortunately the mutate() build won't allow us to change the ProducesRequestCondition. It only has a produces(String...) version. I think we need a version that will allow us to set the ProducesRequestCondition directly.

Either that, or we need to change the BasePathAwareHandlerMapping contract.

[odrotbohm]

I have a fix ready that customizes the ProducesCondition and then extracts the media types to pass them into the produces(…) method. This looks like a bit of extra work but does the trick for now. Just waiting for @mp911de decision on when we can actually merge this as it requires Spring Data to upgrade to 5.3.4 snapshots.