feat: add generic webhook receiver

[krancour]

Fixes #4486

Example usage using expr-lang:

apiVersion: kargo.akuity.io/v1alpha1
kind: ProjectConfig
metadata:
  name: webhooks-demo
  namespace: webhooks-demo
spec:
  webhookReceivers:
  - name: my-receiver
    generic:
      refresh:
        predicate: ${{ request.header('X-Kargo-Event') == 'push' }}
        selectors:
          gitRepoURL: ${{ request.body.repository.repo_name }}
      secretRef:
        name: my-receiver-secret
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: my-receiver-secret
  namespace: webhooks-demo
data:
  secret: c295bGVudCBncmVlbiBpcyBwZW9wbGUK

Example usage using exact matches:

apiVersion: kargo.akuity.io/v1alpha1
kind: ProjectConfig
metadata:
  name: webhooks-demo
  namespace: webhooks-demo
spec:
  webhookReceivers:
  - name: my-receiver
    generic:
      refresh:
        selectors:
          gitRepoURL: https://github.com/example/repository.git
      secretRef:
        name: my-receiver-secret
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: my-receiver-secret
  namespace: webhooks-demo
data:
  secret: c295bGVudCBncmVlbiBpcyBwZW9wbGUK

Note the API was designed with future expansion in mind. For instance, if handling of events representing the merge of a PR were added in the future, the above could be updated without any interference to what it's already doing:

# ...
spec:
  webhookReceivers:
  - name: my-receiver
    generic:
      refresh:
        predicate: ${{ request.header('X-Kargo-Event') == 'push' }}
        selectors:
          gitRepoURL: ${{ request.body.repository.repo_name }}
      prMerge:
        predicate: ${{ request.header('X-Kargo-Event') == 'merge' }}
        selectors:
          prNumber: ${{ request.body.pr.id }}
      secretRef:
        name: my-receiver-secret

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	d80e020
🔍 Latest deploy log	https://app.netlify.com/projects/docs-kargo-io/deploys/68556238717bf200085de602
😎 Deploy Preview	https://deploy-preview-4408.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

❌ Patch coverage is 85.27607% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 53.14%. Comparing base (56e4936) to head (d80e020).
⚠️ Report is 369 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/webhook/external/generic.go	81.81%	22 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4408      +/-   ##
==========================================
+ Coverage   53.00%   53.14%   +0.13%     
==========================================
  Files         356      357       +1     
  Lines       31605    31750     +145     
==========================================
+ Hits        16751    16872     +121     
- Misses      13990    14012      +22     
- Partials      864      866       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[krancour]

Having separate fields for each of the supported repo types does two things:

1. It allows specifying separate repo URL extraction logic for each kind of repo, making it possible, for instance, for one generic receiver to process push events for multiple types of repos.

2. It allows us to know what kind of normalization process to apply to the URL, as the logic for normalizing each of Git, image, and chart URLs is different.

[hiddeco]

If I am understanding this correctly, a predicate is always required and it's not sufficient to declare e.g. artifactPush without one?

[krancour]

As things stand currently, yes.

I had thought about blindly jumping into seeing if the other expressions evaluate to anything, but that seems to invite in the possibility that one or more of those expressions do coincidentally evaluate to something, but the actual event we're being notified of is not one of interest.

By way of example, ignore for a moment that we have a dedicated receiver for GitHub, and imagine we're using a generic receiver to handle incoming webhooks from there. Nearly all event types include repository.url in the payload. The predicate request.header('X-GitHub-Event') == 'push' would prevent us from blindly reading repository.url from an event that turned out to be, for instance, someone adding a comment to an issue.

Please note that I think this works well, but I'm not entirely convinced that there isn't a more ergonomic option I am overlooking, so if you have ideas, I'm totally open to them.

[krancour]

There's too much discussion to be had about this for this to reasonably make it into 1.7.0. Deferring to v1.8.0.

[krancour]

@fuskovic you've worked extensively on the webhook receivers and have worked quite a bit with expressions recently. You're sitting right at the intersection of the things involved in this...

I'm going to turn this over to to you. Feel free to either build on what I've done or scrap it and start fresh if that's what ends up making more sense, but either way, don't start any work on this until we have 1.8 buttoned up and until you, @hiddeco, and I can meet to hammer out what a reasonable UX looks like here... previous conversation between @hiddeco and myself was offline, but revealed that there are a lot small concerns that aren't addressed by this PR.

[krancour]

Closing in favor of #5305