config: separate wildcard hosts where possible

[kenjenkins]

Summary

Envoy supports virtual hosts with wildcard domains, as long as the wildcard token appears at the very beginning or the end of the domain (that is, Envoy supports suffix and prefix domain wildcards). Update the configuration builder logic to take advantage of this support whenever possible, using the current regex route matching as a fallback.

This may improve routing performance in some cases, by reducing the size of the routing table for the catch-all virtual host.

Add a utility method isSpecialWildcardHost() to determine whether a host has a wildcard token that is not at the very beginning or end. Update the existing route configuration test to add one of these special wildcard hosts.

Related issues

User Explanation

Improve routing performance when many routes have * at the beginning or end of the from address.

Checklist

• reference any related issues
• updated docs
• updated unit tests
• updated UPGRADING.md
• add appropriate tag (improvement / bug / etc)
• ready for review

[coveralls]

Coverage: 63.67% (+0.2%) from 63.509% when pulling 9acbbd0 on kenjenkins/wildcard-virtual-hosts into fe8e788 on main.

[calebdoxsey]

This makes sense to me. I don't know if we use the routable hosts anywhere that wouldn't understand *, but if its just used for the virtual host I think it should work.

[calebdoxsey]

So re-reading the docs, there's a subtle difference here. For us *x would match just x whereas with virtual hosts *x means at-least-one character for *. .* vs .+ in regex.

[kenjenkins]

Yes, it looks like there is a subtle difference between the current regex behavior and Envoy's wildcard handling. However, I think Envoy's behavior is reasonable. (To my knowledge it matches the behavior of wildcard certificates, for example.) Off hand, I can't think of a use case where I would want a wildcard to match the empty string.

Do you think this would be an acceptable change in behavior?

(If users really want a wildcard to also match nothing, they could work around this change by adding a duplicate route without the wildcard token.)

[abl]

We do have this exact case - we want to match anything.and.everything.yourmachine as well as yourmachine but we don't want to match notyourmachine.

So what we really need is /^(.+\.)?yourmachine$/, which sort of makes sense conceptually (my domain and any subdomains thereof), but does not neatly map in to how wildcards in A/CNAME records or in certs work today.

[desimone]

Holding off until we can be sure we can support the resulting expansion in route table for our users' deployments.