system webhooks spewing too much data

Hi. We've been monitoring the operation of the tag2upload service system, including the global ("system") webhook that @zigo helpfully configured for us.

It turns out that Gitlab sends a whole slew of events to every system webhook. This is IMO bizarre but it is (if you read carefully) documented, as explained by upstream in the ticket I filed there, https://gitlab.com/gitlab-org/gitlab/-/issues/558030

Looking at the information being sent, I do not consider it appropriate to be logging it in the tag2upload service manager's debug log. (It includes some personal data, including ssh key changes and login failure events, although nothing really serious.)

I consider the tag2upload service manager (the webhook receiver) to have a pretty high level of software and management integrity. So I think sending the data to that service, secured by webpki TLS, and immediately discarding it there, is probably tolerable.

But others may disagree. Also, system webhooks may have been set up for other services, possibly with lower levels of assurance. (Although: the data originates in Salsa which is not really a super high security system, given its wide attack surface, many users, and large amounts of code.)

I think we have these options:

1. Only set up system webhooks for services with a "high enough" level of protecction, whatever that is, and arrange that they discard unwanted events early.

2. Set up an intermediary service that filters out unwanted events and forwards the webhook calls to real receivers.

If you choose 2, I guess I'm volunteering to set up the intermediary service, but it would take a little while. Note that the each webhook would still need to be configured on salsa, probably with some annoying mangled URL. This would avoid the intermediary service needing to be stateful so that it can track retries separately for each recipient, and avoid it needing to have separate configuration. But I'm hoping you will consider 1 sufficient, at least for now.

If you choose 1 or don't reply :-), we will change the tag2upload service to arrange to not make log entries for webhook events that it isn't expecting.

CC @spwhitton for tag2upload. IDK who the other webhook folks are but I think @enrico was one?