Improve toolchain handling

[matthewhughes934]

Force go to always use the local toolchain (i.e. the one the one that
shipped with the go command being run) via setting the GOTOOLCHAIN
environment variable to local[1]:

When GOTOOLCHAIN is set to local, the go command always runs the
bundled Go toolchain.

This is how things are setup in the official Docker images (e.g.[2], see
also the discussion around that change[3]). The motivation behind this
is to:

• Reduce duplicate work: if the toolchain version in go.mod was
  greated than the go version, the version from the go directive
  would be installed, then Go would detect the toolchain version and
  additionally install that
• Avoid Unexpected behaviour: if you specify this action runs with some Go
  version (e.g. 1.21.0) but your go.mod contains a toolchain or go
  directive for a newer version (e.g. 1.22.0) then, without any other
  configuration/environment setup, any go commands will be run using go
  1.22.0

This will be a breaking change for some workflows. Given a go.mod
like:

module proj

go 1.22.0

Then running any go command, e.g. go mod tidy, in an environment
where only go versions before 1.22.0 were installed would previously
trigger a toolchain download of Go 1.22.0 and that version being used
to execute the command. With this change the above would error out with
something like:

go: go.mod requires go >= 1.22.0 (running go 1.21.7;
GOTOOLCHAIN=local)

[1] https://go.dev/doc/toolchain#select
[2] https://github.com/docker-library/golang/blob/dae3405a325073e8ad7c8c378ebdf2540d8565c4/Dockerfile-linux.template#L163
[3] docker-library/golang#472

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[matthewhughes934]

Testing this action https://github.com/matthewhughes934/setup-go-test, see the workflow runs for details https://github.com/matthewhughes934/setup-go-test/actions

[kaovilai]

This PR effectively addresses and fixes #457.

The implementation:

• ✅ Sets GOTOOLCHAIN=local to prevent automatic toolchain downloads (matching Docker's approach)
• ✅ Reads toolchain directive from go.mod/go.work files with proper fallback to go directive
• ✅ Includes comprehensive test coverage for the new functionality

This change will prevent the unexpected behavior where specifying go-version: 1.21.0 could result in 1.22.0 being used due to toolchain directives, exactly as described in issue #457.

The breaking change is well-documented and justified - users who rely on automatic toolchain downloads will need to adjust their workflows, but this brings the action in line with official Go Docker images and provides more predictable behavior.

[reneleonhardt]

Did you rebase already? GitHub doesn't allow me to see the parent commit.
npm packages are very old, maybe npm audit --fix will help after rebasing.

[matthewhughes934]

Did you rebase already? GitHub doesn't allow me to see the parent commit. npm packages are very old, maybe npm audit --fix will help after rebasing.

The vulnerability reported is also present on main:

$ git checkout main
$ git rev-parse HEAD
8e57b58e57be52ac95949151e2777ffda8501267
$ npm audit --audit-level=high
# npm audit report

form-data  >=4.0.0 <4.0.4 || <2.5.4
Severity: critical
form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
fix available via `npm audit fix`
node_modules/@azure/core-http/node_modules/form-data
node_modules/@types/node-fetch/node_modules/form-data
node_modules/form-data

1 critical severity vulnerability

To address all issues, run:
  npm audit fix

The vulnerability is two days old: GHSA-fjxv-7rqg-78g4, here's a separate PR for that #618 (though I'm not sure why dependabot hasn't raised one?)

[reneleonhardt]

Dependabot doesn't always work as you would expect, it's not resilient for example, a simple network error can disable updates. Here is your failed run from 2 days ago, only maintainers are allowed to read the logs:
https://github.com/actions/setup-go/actions/runs/16426449639
It doesn't even store state between runs, and when you only allow it to run once per week like in this repo, then it could take days or weeks until you finally could merge even one PR again, so contributors can do nothing except waiting even longer when even CI stops working...

As long as AI reviews haven't been enabled, only manual maintainer work could speed-up reviews.
After waiting for one year for a few lines of code, I wouldn't hold my breath...

[matthewhughes934]

I've dropped the commit that changed behaviour from install the Go version specified in the toolchain directive to the one specified in the go directive, since I think this is what people expect this action to do (it's how things worked until toolchains were introduced to the language). Maybe worth a separate option to install the toolchain version.