This PR was merged into the 3.4 branch.Discussion----------[Routing] backport tests from 4.1| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -Commits-------c2e0f97 [Routing] backport tests from 4.1

…ith no explicit slash (nicolas-grekas)This PR was merged into the 4.1 branch.Discussion----------[Routing] dont redirect routes with greedy trailing vars with no explicit slash| Q             | A| ------------- | ---| Branch?       | 4.1| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#29673#29734#29575| License       | MIT| Doc PR        | -From the linked issue:> The current logic is the following:> - when a route is declared with a trailing slash, the trimmed-slash url is redirected to the one with the slash> - when a route is declared with *no* trailing slash, the slashed url is redirected to the trimmed-slash one>> That includes routes with slash-greedy requirements: when the same greedy requirement matches both the slashed and the trimmed-slash URLs, only one of them is considered the canonical one and a redirection happens.>> We could fine tune this logic and make an exception when a trailing slash-greedy requirement is declared with no explicit trailing slash after it. (ie disable any redirections for `/foo/{.*}` but keep it for `/foo/{.*}/`. That would mean `/foo/bar` and `/foo/bar/` wouldn't trigger the redirection for route `/foo/{.*}`, breaking the "not-semantics" property of trailing slashes for catch-all routes. Which might be legit afterall.This PR implements this fine tuning, as that's the most BC behavior (and thus the correct one).See#30012 for `testGreedyTrailingRequirement` in action on 3.4 as a proof.Commits-------2bb8890 [Routing] dont redirect routes with greedy trailing vars with no explicit slash