Change conflicting FQDN logic in HTTPProxy

[sunjayBhatia]

Sort HTTPProxies when checking for FQDN conflicts so that the oldest is still set as Valid so multiple tenants cannot affect each other, e.g. resources across namespaces should not be able to invalidate the original "owner" of the FQDN.

Similar to the Gateway API conflict resolution logic here: https://gateway-api.sigs.k8s.io/guides/api-design/#conflicts

Useful for cases where Gatekeeper policies are not feasible to apply.

[sunjayBhatia]

WIP, still needs tests

[tsaarni]

Looks good to me! This way we keep traffic up as long as possible and avoid failing existing HTTPProxies. I’m not sure if this could introduce any backward compatibility issues? I suppose anything is possible, but it seems quite unlikely that someone would depend on creating conflicting proxies and having them all fail. It might be surprising if Contour starts accepting one, but maybe bit unlikely to cause issues.

I’m also not sure I understand the reasoning behind the last criteria in https://gateway-api.sigs.k8s.io/guides/api-design/#conflicts, where the first resource in alphabetical order wins. That feels like an arbitrary, not serving the goal of keeping traffic up as long as possible. But since Gateway API defines it that way, having consistent behaviour for HTTPProxy can make sense.

It looks like the existing code already includes conflicting resource names in the error message, so I assume the winning proxy name should be included in the status of failed ones. Though, I wonder if exposing that information could be used by someone with access to one namespace to enumerate HTTPProxy names in other namespaces for any given FQDN. It is good for troubleshooting and it is not clear what risk that information could have, but it is still "leaking" information cross namespace border.