Enable/disable host name collision prevention

[guicassolato]

Authorino currently does not allow AuthConfigs to take control over the security scheme of hosts already protected by other AuthConfigs created previously. The behavior is described at Avoiding host name collision in the docs, and it is in general a good safe default.

There are use cases nonetheless where host ownership can be managed upfront by other means, such as by validating the AuthConfig CRs beforehand, at the level of the kube API requests (e.g. via a validating webhook, or by enforcing more strict RBAC that constricts write permissions over the CRs to highly privileged cluster users only, amongst others), or when the host information and corresponding auth scheme association is known to be reconciled always from a known trusted source of truth. For such cases, disabling the prevention of host name collision mechanism may be desirable.

A concrete use case is Kuadrant. The Kuadrant Operator manages Authorino AuthConfigs created out of its watched AuthPolicy CRs. Often, an AuthPolicy resource that targets a more generic network structure (e.g. a Kubernetes Gateway resource, or a wildcard HTTPRoute) is followed by a more specific one with a different auth scheme. Leveraging Authorino's "most specific host wins" policy, both schemes can live side-by-side, but only if the more specific AuthConfig is created first. Otherwise, the more specific hosts in the AuthConfig created after will be rejected, causing this resource to be reported as not ready.

To enable such use cases, Authorino could put the mechanism that prevents host name collisions behind a switch.

The switch could be set at the level of the Authorino instance or for each individual AuthConfig, and would effectively allow an AuthConfig to take control over the auth scheme (i.e. to be "indexed") for hosts already protected by other AuthConfigs created previously.

Instead of a simple ON/OFF switch, it could be set at levels:

• Level 0 - No override
• Level 1 - Partial overrides only (hosts that are strict subsets of the ones already protected by other AuthConfigs)
• Level 2 - Full overrides (including identical hosts)

For level 2 in particular, one caveat to take into consideration is the status update of the resources that are fully overridden by other AuthConfigs created after. This is currently not a concern due to the assurance that the resource with the earliest creation timestamp always prevails, even in the cases of (re)building the index from preexisting AuthConfig stored in etcd. By allowing full overrides, some (older) AuthConfigs will be de-indexed. Their status stanzas should reflect that, including for the sake of reliable readiness check.

[guicassolato]

Just realised we should avoid using "override" for describing the behaviour associated with this proposed switch, to prevent any confusion with the concept of overriding hosts via context extensions.

I'll try to favour "supersede" instead, thus sticking with the terminology employed in the docs associated specifically with the prevention of host name collisions.