Use REQUEST_URI instead of PATH_INFO - #18050

Switch to using REQUEST_URI (via diactoros/Uri) instead of reading from
PATH_INFO. The PATH_INFO value includes URL decoding which can allow
encoded URLs to match routes when they shouldn't.

Remove urldecode in RouteCollection

This was contributing to %2f getting through routing. We have to retain
backwards compatibility with urlencoded path segements as users expect
those to be exposed to application code in a decoded state.

Backport of #18050 to 4.x

Use REQUEST_URI instead of PATH_INFO (#18050)

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.

Handle %2f in routing more consistently

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.

Handle %2f in routing more consistently

Currently path prefix matching does not treat %2f as /, and `Route` has
an option for it. In the past we've made changes in this area
(#18050, #16110) to make urldecoding optional, and to intentionally
decode urlencoding in path segments to support non-ascii applications.

We got a report on the security list for a potential issue where *if*
an application enforced authorization within path prefixed scopes, and
had fallback routes enabled, then one could potentially bypass the scoped
middleware and hit the fallback routes which inconsistently handle %2f.

These changes align the behavior of urldecoding between RouteCollection
and Route with a new shared internal function. I thought a function was
better than exposing a static method on a public class.

Thanks to Rotem Reiss for reporting this issue.