(7.4.z) UNDERTOW-2200 UndertowOptions#ALLOW_ENCODED_SLASH has opposite effect and parts of path/query are decoded in bad way

Check linked ticket desc.

UPDATE: path& query parameters are not decoded properly due to flag/meaning switch of flag:
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/util/URLUtils.java#L95 --> decodeSlash
vs
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/protocol/http/HttpRequestParser.java#L587 --> allowEncodedSlash

https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/util/URLUtils.java#L95 --> decodeSlash
vs
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/protocol/http/HttpRequestParser.java#L587 --> allowEncodedSlash

This means that not only parts of code had wrong value hardcoded, but UndertowOptions#ALLOW_ENCODED_SLASH had opposite meaning.

Using a predicate path-prefix('/foo') -> rewrite('/bar${remaining}') for a request path that already has some url-encoded segments will result in rewritten path being different than intended. 

For example, a request to /foo/hello%2Fworld will end up being /bar/hello%252Fworld instead of the expected /bar/hello%2Fworld

I noticed this problem on WildFly in a JAX-RS method that must handle such urlencoded values in a @PathParam