Automatically track upstream boring CLs

[qmuntal]

Upstream can add our update the boring package and its usage at any time. We need to know about these changes as they are submitted for review, so we have enough time to update our OpenSSL and CNG bindings.

We currently have two methods to spot boring changes:

• If we are lucky, the upstream change conflicts with our patches, so we have to fix it yes or yes. This would have been the case of the big go1.19 refactor if we hadn't notice it in advance. Historically, boring CLs are merged at the end of the development cycle, so relying on this method does not give us enough time to do the work before the next release comes.
• If we are disciplined and manually monitor Gerrit, i.e. using this query, we will see any submitted for review CL way before it is merged. For example, last week I saw https://go-review.googlesource.com/c/go/+/423363 by chance.

Relying on our luck or our discipline is not sustainable in the long-term, so I propose we run a scheduled CI job that queries Gerrit looking for potential boring CL candidates and that creates a tracking issue on our side.

[dagood]

scheduled CI job

I think the importance of state ("have I seen this one before") and potentially wanting to poll rapidly (more than once a day) might tip this towards making an actual service. Say, an Azure Function on a timer with a database.

The nice thing about AzDO CI jobs is the built-in traceability and access to secrets--we can mitigate by giving our service an account with no permission in the main repos.

[qmuntal]

It seems that Gerrit already supports this use-case via Email Notifications. One can subscribe and get notified when something happens in Gerrit, and its customizable enough to filter boring-related changes.

Still investigating, will report out when I have the full thing set up.