feat: support CEL string expressions for custom commit statuses in v1beta3 provider type

[kathleenfrench]

Closes #589

this change was enabled by recent work to enable RFC-0008 which allows for custom metadata to be injected in flux events.

we can leverage the flux runtime pkg cel library's support for compiling and evaluating strings (added in fluxcd/pkg#882) to compute a commit status for git provider types (github, gitlab, gitlea, bitbucketserver, bitbucket, and azuredevops) that can make use of end-user provided event metadata along with standard values accessible to event, provider, and alert.

CEL expresions with this feature can only reference: event, provider, and alert.

to accomplish this, a new optional field is added to the v1beta3 provider spec called commitStatusExpr.

following some additional discussions, it was elected to not re-add the status subresource to the provider to make way for these changes, but instead evaluate the CEL expression from the event server and forward the commit status to the relevant factory, if it exists/is applicable.

as part of this effort a few things to note:

• the notifier factory constructor has been refactored
• the ProviderUID notifier option has been removed from git providers in favor of CommitStatus, which is computed prior to creation of the notifier either via the custom expression or using the (status quo) default commit status generator function which combines the involved object kind, name, and provider UID.
• all git factory function signatures have been altered to sub commitStatus for providerUID -- error handling + tests have been added to ensure the status cannot be empty on creation of the factory, though this is just a failsafe measure and should not happen given if a custom expression is used and fails we drop the alert and if no custom expression is provided we use the pre-existing logic, just evaluated sooner rather than in Post.
• we run combineEventMetadata() prior to creating the notifier now

so to recap: if the commit status expression fails to compile or evaluate we:

• log the error removed based on pr feedback
• emit a warning event removed based on pr feedback
• return an error
• drop the alert

if no commit status expression is provided and the provider is a supported git type, we generate a default commit status using event metadata and the provider UID with the same, existing logic just sooner in our handling of the event/alert. if the provider is not a git type, the commit status forwarded to createNotifier is an empty string.

[matheuscscp]

Thanks very much for this contribution @kathleenfrench!

First pass 😁 Will do another one tomorrow

[matheuscscp]

Amazing work here @kathleenfrench!

[matheuscscp]

LGTM!

Thanks very much for this contribution @kathleenfrench! 🚀

[matheuscscp]

Btw I tested this feature in a real cluster and it works:

[stefanprodan]

LGTM

Thanks @kathleenfrench 🥇