Enhance UrlHandlerFilter with ordered pattern matching and status validation

[jamesmissen]

This PR addresses issue #35882.

It does the following:

1. Allows for ordering handlers based on path specificity, so handlers are selected based on how well a PathPattern matches the request path.

2. Validates the HTTP status code for redirect handlers, using a simple assertion to check if the code is 3xx.

The changes are backwards compatible:

1. A new useSpecificityOrder method is added to the Builder to opt in to specificity-based ordering. Not using this method (or using a value of false) results in the current behaviour.

2. A new exclude method is added to the Builder to optionally exclude URL handling for specific patterns. Not using this method results in the current behaviour.

3. For the servlet implementation, the parameter of the redirect method was changed from type HttpStatus to HttpStatusCode to align with the reactive implementation. This change will have no effect as HttpStatusCode is implemented by HttpStatus.

Feedback and edits are welcome, particularly regarding the implementation of specificity-based ordering, and the new method names (useSpecificityOrder and exclude).

[rstoyanchev]

Thanks for the changes.

The extraction of the lookupPath as a subpath is a breaking change. I appreciate the proposal, but as implemented it will break any application with a context path. This needs to be opt-in, e.g. excludeContextPath().

The idea with excludes was not in the original description and has not been discussed. If using specificity order, it seems like it can end up in the wrong order if mixed with all regular patterns. If using order of registration, one has to be careful to specify those first and they would always have to be checked first adding overhead. I don't quite see the use case for this in combination with trailing slash handling. Did this come from an actual use case? I would prefer to take it out and consider it separately, and as a general rule of thumb, it's best to split out extras like that so it doesn't hold up the rest of the PR.

For useSpecificityOrder, maybe sortPatternsBySpecificity().

For the HandlerRegistry abstraction, I didn't try but it seems the two implementations can be merged into one by using Map<PathPattern, Handler> where the implementation is either LinkedHashMap or TreeMap. That would remove the need for a HandlerRegistry abstraction in the first place, and significantly simplify the implementation.