chore(all): restore go 1.22 in go.mod

[quartzmo]

fixes: #3009

[codyoss]

I don't think we can make this change because of our dependencies have a patch level specified in thier go.mod.

[quartzmo]

In Kokoro, it fails the go.mod diff check in latest-version (below).

+ cd /root/go/src/google.golang.org/api/
+ try3 go mod download
+ eval 'go mod download'
++ go mod download
+ ./internal/kokoro/vet.sh
+ [[ cloud-devrel/client-libraries/go/google-api-go-client/presubmit/latest-version != *\l\a\t\e\s\t\-\v\e\r\s\i\o\n* ]]
+ go mod tidy
+ tee /dev/stderr
+ read
+ git diff go.mod
diff --git a/go.mod b/go.mod
index 3e19e7de8b..b48b684637 100644
--- a/go.mod
+++ b/go.mod
@@ -1,6 +1,8 @@
 module google.golang.org/api
 
-go 1.22
+go 1.22.7
+
+toolchain go1.23.5

[quartzmo]

The dependency that forces 1.22.7 here is one that is under our control:

go: cloud.google.com/go/auth@v0.14.1 requires go@1.22.7, but 1.22 is requested

But unfortunately, that library has a dependency that is NOT under our control:

go: go.opentelemetry.io/auto/sdk@v1.1.0 requires go@1.22.0, but 1.22 is requested

[matthewhartstonge]

I've created a minimal repro: https://github.com/matthewhartstonge/exp-gomod-toolchain-resolution

But yeah, the issue does seem to be the otel upstream dep.

Setting v1.22.0 should solve it, but may force downstream to set the patch.
But adding a 0 to the go directive is better than having to manage the toolchain directive.

[codyoss]

To me this is a Go ecosystem class of issue. I think this feedback on managing go versions should likely be reported upstream to the Go project if it has not already.

[quartzmo]

@codyoss golang/go#65847

[quartzmo]

@matthewhartstonge I'll investigate the possibility of setting v1.22.0 in our libraries separately. Closing this PR as it is currently a no-op.

[codyoss]

@quartzmo That talks to the toolchain aspect, but the Go version part is likely a seperate and maybe even more contentious topic.