Implement Receiver resource filtering with CEL

[bigkevmcd]

This implementation allows filtering of wildcarded resources for receivers using CEL expressions.

Closes: https://github.com/fluxcd/notification-controller/issues/491

Spec: https://github.com/fluxcd/notification-controller/issues/491#issuecomment-2404615301

[bigkevmcd]

@stefanprodan @matheuscscp I reworked it to filter the resources using CEL.

I'm not quite sure that this is really that valuable, I suspect label filtering is also more efficient?

There's some optimisation of the CEL that could be done within requestReconciliation to reduce the creation of CEL values and I can do that but I thought I'd get this out for comment.

[stefanprodan]

@bigkevmcd this is good to go, please signoff all your commits and force push.

[bigkevmcd]

@darkowlzz It'll be a couple of weeks before I can devote more time to these things, but I will get to them.

[bigkevmcd]

@pjbgf

+1 on leaning on k8s' default limits as a starting point. It might be worth just confirming whether the payload and expression sizes for this use case are equivalent, so that those limits would not be too forgiving.

https://github.com/kubernetes/kubernetes/blob/cf480a3a1a9cb22f3439c0a7922822d9f67f31b5/staging/src/k8s.io/apiserver/pkg/apis/cel/config.go#L40

That's 3MiB, I've definitely seen GitHub hook notifications that were > 1.5MiB.

[matheuscscp]

@bigkevmcd we have released the fluxcd/pkg packages, please pull them in with:

• go get github.com/fluxcd/pkg/apis/[email protected] for InvalidCELExpressionReason
• go get github.com/fluxcd/pkg/[email protected] for the runtime/cel library

:pray:

Edit: Like Stefan said below, just need to rebase.

[stefanprodan]

@bigkevmcd if you rebase with main, you'll find runtime/cel and the InvalidCELExpressionReason.

[matheuscscp]

Thanks very much for this contribution @bigkevmcd ! :rocket: :rocket: :rocket: