RFC: Alert CR support for wildcard namespace

[dm3ch]

/relates fluxcd/notification-controller#504
/relates fluxcd/notification-controller#71
/relates #4095

RFC covering support of monitoring all namespaces by Flux Alert.

[dm3ch]

@matheuscscp You proposed to bring this feature discussions as a RFC.
Since I'm new to this RFC process and didn't understand what the sponsor means in the readme, I'm kindly asking you to assist or at least consult me how to start the discussion process properly.

[matheuscscp]

This RFC will hardly get through. I don't see anybody in the maintainers team interested in evaluating or considering the possibility of introducing a mechanism that breaks Kubernetes namespace isolation in such a... simplistic, or niche way. The Flux project has been historically trying to move away from this (a.k.a. --no-cross-namespace-refs), and I will not agree with introducing such a security boundary breakage the way it's proposed here. The --no-cross-namespace-refs flag came later to fix the unfortunate introduction of cross-namespace references in Flux. In my opinion, it should not be used as a standard for introducing more cross-namespace reference features. In hindsight, cross-namespace reference features would never exist in Flux.

If there's a big desire from the Flux community to have proper support for cross-namespace references, I'd lean more towards the ReferenceGrant API. Looking at the KEPs it didn't seem like they were utterly rejected, but rather simply deprioritized. I wouldn't be surprised if they eventually converged to something better, given that ReferenceGrant is looking really bad under the API group gateway.networking.k8s.io, and other SIGs have already started using it. I'm pretty sure that if somebody showed up willing to push and contribute their time in this standardization they would probably appreciate the help. In an ideal world, Flux should integrate with a consolidated ReferenceGrant API (and not build one under something.toolkit.fluxcd.io).

ReferenceGrant will, however, take a long time.

A specific point brought up in this similar RFC that I would be willing to consider is:

https://github.com/rsafonseca/flux2/blob/090a3e6c616eac5986af878d365d6699419f89a7/rfcs/0005-global-objects/README.md?plain=1#L27-L29

It seems reasonable to me that cluster administrators may not want to share notification provider secrets with tenants. For this I would be willing to consider a controller-level flag that allows specifying a fallback secret in the same namespace of the controller pod (like we're gonna do here). Would this be useful?