fix: retry the Go module fetch in every Go sample's Dockerfile - #245

Problem

proxy.golang.org now and then resets an HTTP/2 stream partway through a module download:

go: golang.org/x/text@v0.31.0: read "https://proxy.golang.org/...": stream error: stream ID 187; INTERNAL_ERROR; received from peer

The next attempt succeeds. But every Go sample's Dockerfile here fetched its modules exactly once, using a bare go mod download, a bare go mod tidy, or a go build that fetches what it needs. One reset therefore fails the image build. It also fails the CI lane of whichever keploy repo was running docker build on the sample: keploy/keploy's workflows and other keploy CI clone this repo at main and build these Dockerfiles. This repo's own build.yml has the same exposure through its bare go build ./....

Changes

1. fix: retry the Go module fetch in every Go sample's Dockerfile (27 Dockerfiles). Each fetch now runs in a loop: 5 attempts, 5-20s apart, then the build fails.

   RUN n=0; until go mod download; do n=$((n+1)); [ "$n" -lt 5 ] || exit 1; echo "go mod download failed (attempt $n), retrying in $((n*5))s"; sleep $((n*5)); done
   

   • The 19 bare go mod downloads and go-grpc's two go mod tidys run in the loop.
   • echo-sql, gin-redis, mux-mysql, sse-svelte and users-profile fetched inside go build. They now run the looped go mod download first.
   • nethttp-mysql's go mod download || true ignored a failed fetch and left it to an un-retried go mod tidy. Both are looped now.

   A module fetch is idempotent and fails only because of the network, so retrying it is safe. A missing module or a bad go.mod fails every attempt and still fails the build.

2. fix(gin-redis, gin-pulsar): build them on a Go their go.mod accepts. Neither image built before this PR. gin-redis's go.mod needs Go 1.23 but the image was golang:1.20; gin-pulsar's needs Go 1.25 but the image was golang:1.23.

3. ci: retry each sample's module fetch before building it. build.yml now runs go list -deps ./... in a loop, the same 5 attempts, before each go build ./.... go list -deps loads the same packages go build loads, so it fetches nothing more.

Verification

• All 27 changed Dockerfiles were built on a test machine: 25 built. gin-pulsar and gin-redis failed for the same reason the unchanged Dockerfiles fail, and both build after commit 2. docker build --check reports no warnings on any of them.
• A GOPROXY was set up that cuts the first download of one module partway:
  • The unchanged go-docker-timefreeze and go-grpc server Dockerfiles fail with unexpected EOF (on golang-jwt/jwt v5.3.0 and on grpc v1.69.2). The looped ones recover on the second attempt.
  • The same holds for build.yml's step: the old step fails on go-docker-timefreeze, and the new one recovers.
• build.yml's step was run as written, with Go 1.27.0 and an empty module cache: all 44 modules build, both with and without this change.
• keploy/keploy's and keploy's other CI were searched for sed edits to these Dockerfiles. The only one rewrites go-docker-timefreeze's RUN CGO_ENABLED=0 GOOS=linux go build -o /main . line, and this PR leaves that line unchanged.