feat: allow webhooks to specify consumer version matchers for when they are triggered

[bethesque]

Having done the "support triggering a verification build for each deployed version of the provider when the pact changes" the other day, I realised that we only want to do that for change to the master pact. Feature branch changes are irrelevant, and will just result in tying up build nodes that could be doing better things. I've been meaning to add better support specifying when a webhook should run for years, so now I've finally done it.

This PR adds support for consumerVersionMatchers in a webhook, that let you specify which branches or tags a webhook should be triggered for. One thing I'm not sure of - should they be called consumerVersionMatchers or consumerVersionFilters. I don't want to override the "matchers" term, given we already have that in the pact terminology.

I'll eventually add providerVersionMatchers/Filters too, but this is currently just solving my own problem 😆 Allowing both consumer version and provider version matchers will allow us to do things like "only do something when a master verification for a master pact comes in". I envisage people wanting "not" filters and regex filters too.

[mefellows]

Very cool!

"Selector" also comes to mind, because it's used elsewhere as a sort of filter. But I can see why you may not want to override that term, so "filter" is the next best one :)

[bethesque]

Just doing some more thinking on this. I imagine that we'll want events for "pacticipant_deployed" and other things that are not consumer/provider specific (eg. someone has just asked for a "tag created" event). In that case, we'll want versionFilters, not consumerVersionFilters and providerVersionFilters. Trying to think of a format that will support non-role specific filters, as well as role specific filters (eg. for a pact verification, you might want to filter on the provider branch or the consumer branch, or both).

I had imagined that you could specify multiple filters, and they would OR together.

This would mean: fire the webhook when branch is main OR tag is prod.

{
   xVersionFilters: [{ branch: "main" }, { tag: "prod" }]
}

The consumer/provider ones would AND together though, so this would mean, "when consumer branch is main AND provider branch is main".

{
   consumerVersionFilters: [{ branch: "main" }],
   providerVersionFilters: [{ branch: "main" }]
}

That's not particularly intuitive though. I'd really rather not have to implement a massive matcher And/OR thing.

Ugh! This is why I've aways told people to make the webhooks dumb, and to put all the logic in the triggered build, which could then trigger another build based on their own custom logic. 😱