x/build/cmd/updatestd: ability to split large updates into a sequence of smaller update CLs, for better bisection

[dmitshur]

At this time the updatestd command updates all golang.org/x versions to latest available when it is run. If run fairly infrequently (e.g., twice per cycle, so every 3 months), there can be many changes in all golang.org/x dependencies, and they're currently all included in one CL.

For purposes of improving the ability to bisect and find a narrower set of changes that may have introduced a problem, it would be better to split such large updates into multiple smaller CL.

Comment #36905 (comment) makes this suggestion.

A strategy of making a CL per module may not scale in the general case: updating to the latest version of module A may cause newer versions of module B to be also pulled in, and since module requirements can have loops, module B can also require newer module A.

Another strategy to consider is to split the large update by time: instead of updating from "3 months old" versions to "latest" directly, it can be "update to versions that were latest 2 months ago", then "update to 1 month old", then finally "latest latest". This can be automated, and needs to be careful to avoid making CLs that move some dependency versions back in time.

There's like some overlap here with issue #41589, but they're not the same.

CC @golang/release, @bcmills.

[dmitshur]

There's some overlap with #48523 here. There can be a higher-level service that takes on what needs to be done for both of these issues.