Consider passing GOPROXY in x-pack/metricbeat during integration tests

[dliappis]

This issue is related to #42443 but it's more about the why and a shorter term solution, rather than the longer term solution.

As discovered in the PR #42358, mage goIntegTest (and also Python Integ Tests) fail while downloading the indirect dependency for go.opencensus.io. The dependency comes from dgraph-io/badger (more details in #42443 and dgraph-io/badger#2155).

The error we are getting comes from the cloudfoundry module (link) and looks like:

go: downloading github.com/cespare/xxhash/v2 v2.3.0
/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/levels.go:35:2: unrecognized import path "go.opencensus.io": https fetch: Get "https://go.opencensus.io/?go-get=1": EOF

=== Errors
/go/pkg/mod/github.com/dgraph-io/badger/[email protected]/levels.go:35:2: unrecognized import path "go.opencensus.io": https fetch: Get "https://go.opencensus.io/?go-get=1": EOF

DONE 0 tests, 1 error in 241.183s
Error: failed to run integration tests for module cloudfoundry:
1 error: failed to execute go: exit status 1
Error: failed modules: cloudfoundry
Error: failed to run integration tests for module cloudfoundry:
1 error: running "docker-compose -p metricbeat_8_17_2_05e15fcbbb-snapshot run -e DOCKER_COMPOSE_PROJECT_NAME=metricbeat_8_17_2_05e15fcbbb-snapshot -e BEAT_STRICT_PERMS=false -e STACK_ENVIRONMENT=snapshot -e TESTING_ENVIRONMENT=snapshot -e GOCACHE=/go/src/github.com/elastic/beats/build/docker-gocache -v /opt/buildkite-agent/.asdf/installs/golang/1.22.10/packages/pkg/mod/cache/download:/gocache:ro -e GOPROXY=file:///gocache,direct -e EXEC_UID=1009 -e EXEC_GID=1010 -e BEATS_INSIDE_INTEGRATION_TEST_ENV=true -e GOFLAGS=-mod=readonly -e MODULE=cloudfoundry -e TEST_COVERAGE=true -e RACE_DETECTOR=true -e TEST_TAGS=oracle beat /go/src/github.com/elastic/beats/x-pack/metricbeat/build/mage-linux-amd64 goIntegTest" failed with exit code 1
Error: failed modules: cloudfoundry

The interesting bit is that e.g. go get github.com/dgraph-io/badger/[email protected] works on the CI worker itself, but fails when invoked via docker-compose as part of the test.

Other projects that have encountered this issue recommend setting GOPROXY='https://proxy.golang.org/,direct', so this could be explored (keeping in mind, though, directly issuing go get ... on the VM seems to work without needing to define GOPROXY.

For now, we had to work around the problem with VM images that have predownloaded dgraph-io/badger/v4 and its dependencies (PR link).