x/example/ragserver/ragserver: requires go1.23.0, so go1.22 builders are redundant with go1.23 builders

[dmitshur]

One of the nested modules in x/example can't be tested on the Go 1.22 release branch, not without upgrading to a Go 1.23 toolchain, as reported by its LUCI builders here (added recently in CL 608495):

https://ci.chromium.org/p/golang/g/x-example-go1.22/console

It's probably fine for some modules in x/example to require Go 1.23 or newer. Perhaps we don't need to test that it works with Go 1.22?

Note that there are already tests for cmd/go toolchain switching behavior elsewhere; so we don't benefit from running all the macOS/Linux/Windows builders with the default GOTOOLCHAIN=local+auto if they'll just repeat the work of equivalent go1.23 builders. We also don't want the dashboard to be red (issue #11811), so filing this to track next steps.

CC @eliben, @mknyszek.

[eliben]

It's probably fine for some modules in x/example to require Go 1.23 or newer. Perhaps we don't need to test that it works with Go 1.22?

Examples - by their nature - demonstrate new features, so it's really valuable to be able to restrict them to only the newest version of Go.

[dmitshur]

Fixed in crrev.com/c/5869577.

Specifically, release branch builders (e.g., x_example-go1.22-linux-amd64) will now skip testing modules that have a go directive that's too high for that particular builder, at least when GOTOOLCHAIN=local is in the environment. Other modules are still tested. Go tip builders don't do this kind of skipping so that accidental go 1.220 directives are caught.