ReplacePath rule executes out of order, when combined with PathPrefixStrip

[aantono]

I believe I found a possible bug, or at least a not intuitive behavior when ReplacePath rule is preceded by PathPrefixStrip
Basically because PathPrefixStrip is a Matcher, but also happens to be a Modifier as well, when combined with ReplacePath, like PathPrefixStrip:/management;ReplacePath:/health, due to the order in which the Modifiers are applied in server.go, the above rule-set does not behave as expected.

While one would expect that we match the request to /management url, strip the /management prefix, followed by a replace with /health. This is NOT, however, what is happening. The matcher does the job correctly and matches the request on /management and sends it down the correct Handler chain, but that's when the issue creeps in.

Because ReplacePath Modifier gets executed first in the Handler chain, it replaces /management with /health, and when StripPrefix Modifier gets called, it is trying to match the Path with /management prefix, and obviously failing to do so, thus returning 404-Not Found.

If the Rule is written as PathPrefixStrip:/management;ReplacePath:/management/health, then everything works, but the actual invocation URL Path ends up being NOT /management/health but /health, thus making this configuration be misleading.

This issue relates to #1374