[maistra-1.1] MAISTRA-224: Support for authorisation regex matching on request headers

[dgn]

This adds back the regex matching on request headers functionality we introduced in #3. I changed it to use the SafeRegex matchers introduced in newer Envoy versions to mitigate the Regex matching CVE.

Upstream, there's a feature flag PILOT_ENABLE_UNSAFE_REGEX=false that by default sets SafeRegex as the default but provides a fall-back for users who cannot change their regular expressions to be compatible with RE2. While this is a sensible migration strategy, I think we should not do the same, for multiple reasons:

1. Setting the feature flag would expose our users to the CVE. Upstream changed the std library so they can safely use libstdc++::regex, we however are stuck with std::regex.
2. Envoy has deprecated the use of the old regex field, so migration has to happen at some point anyway.
3. RE2 covers a lot of ground when it comes to regular expressions. From reading the docs, it appears that the only things that don't work the same as std::regex are complicated back-tracking and 'magic' mechanisms

So there are two approaches here; I suggest we follow 1:

1. We default to SafeRegex everywhere and remove the feature flag, because setting it exposes users to the CVE.
   This is my preferred approach and is followed in this PR: no feature flag is read. A follow-up PR will be needed to remove the feature flag from Route generation.
2. We read the feature flag in our header regex matching code, just as upstream does in the Route generation, to decide which RegEx library to use.
   This would need changes in this PR (adding an if-clause).

[jwendell]

Is there any doc that should be updated as well?

[dgn]

Is there any doc that should be updated as well?

I'm not sure. I guess, because theoretically, old regexes might break. I created an issue in our 1.1.0 sprint to make sure we don't forget that it needs to be mentioned in docs: https://issues.redhat.com/browse/MAISTRA-1116