chore: docker with go 1.22, kuboreleaser with go 1.21

[hacdias]

No description provided.

[hacdias]

@galargh any ideas why the go checks are failing?

[galargh]

Looks like go mod edit -json cannot infer that we're after go 1.22. Weird that other commands don't have this problem. We'll be working on UCI release later this week which means we'll have to deal with it.

[galargh]

@hacdias Our regular, scheduled Unified GitHub Workflows update doesn't face this problem - #35.

I suspect it's because of the toolchain directive the update with go mod tidy -go=... did.
Edit: Looks like it's specific to 1.22 and toolchain doesn't have to be explicitly specified after all - #36
Edit 2: I think I know what's going on. In Go checks, we use the Go version installed on the hosted runner to extract the version from go.mod. The version installed is 1.21.x. When the go.mod has a newer version than the installed, Go tries to download newer toolchain. Since specific toolchain is not specified in the go.mod file, it tries to just download 1.22 toolchain. But that toolchain doesn't exist. All in all, it'll make sense to install latest stable Go in Go check workflow the same way we do it for Go test.

Note that in the other PR, we updated to 1.21 in go.mod file. That's the regular cadence the Unified GitHub Workflows have been following. Is there any reason we want to go skip that?

[hacdias]

@galargh Kubo has been updated to Go 1.22 - so at least the Docker container needs to be updated to Go 1.22 to avoid issues when running the changelog maker. But indeed Kuboreleaser can stay on 1.21