x/build: consider pushing open backport issue milestones automatically at start of each month

[dmitshur]

Right now, the milestones of open backport issues that did not get included in a given minor release are automatically bumped to the next minor release milestone by releasebot at the end of a successful release stage:

https://github.com/golang/build/blob/301a72cb1ab6c95414686a16f34ebe2bef25b689/cmd/releasebot/main.go#L429

Since we generally don't try to include more fixes in a minor release after the start of a month (aside from ones that have release-blocker label, which must be considered), it should be more accurate and clear to push the milestone to the next one at the start of the month.

However, when considering this, we need to be careful so that we don't accidentally land another fix after a month starts and forget to move the milestone of corresponding issue back to the correct previous one.

This issue is likely best to address as part of overall release automation, tracked in #40279 and #29205. /cc @toothrot

Thanks to @mundaym for suggesting this in https://groups.google.com/d/msg/golang-dev/6b-rdo-i8sA/auCA48IhAgAJ.

/cc @toothrot @cagedmantis @andybons

[dmitshur]

I've considered this idea during the development and release of Go 1.15.3 and 1.10.14 releases recently.

Those releases were not made at the beginning of the month because there were release-blocking issues open that needed more time to be resolved. During that time, we had an opportunity to make progress on additional backports.

I think it was helpful that it could be done without needing to move the milestone back on the issues that were fixed (and avoiding the risk of forgetting to do that).

Based on that, it seems the benefit of implementing this change is reduced. I welcome other feedback; I wanted to share my observations so far.