x/build: update gopls version requirements as part of the Go toolchain release workflow

[findleyr]

In https://go.dev/cl/640035, we apparently added an iterator use in gopls that made it susceptible to #70035. Thankfully, this was caught due to our legacy Go version builders. (Aside: this is a use-case for legacy builders that I'd not considered; apart from verifying integration with older Go commands, they also confirm that our minimum toolchain version is adequate).

We'll fix this by updating our minimum toolchain version, but that begs the question: why don't we always update our toolchain requirement to point to the latest patch release? Could we update the Go release workflow to send a CL against gopls? By analogy, we update VS Code following a gopls release.

The only reason that I can think of not to do this is that it may cause users to download more toolchain versions, or cause more friction for users that don't have GOTOOLCHAIN=auto. But given the frequency that we release new gopls versions, this seems acceptable. Am I missing something?

CC @adonovan @h9jiang @dmitshur

[thediveo]

might this conflict with, for instance, devcontainers where I want to have a well-defined tooling?

[seankhliao]

The tooling requirements for your project and for gopls probably shouldn't be conflated.