Dockerfiles use amd64-specific images

[dmitris]

Description
Currently trying to run docker-compose up -d fails on an M1 (arm64) Mac because the golang images "pinned" in the Dockerfiles are amd64-specific, which makes the development on newer Macs difficult. In particular, it leads to failing e2d tests in sigstore/cosign (https://github.com/sigstore/cosign/blob/main/test/e2e_test.sh). How important is it to "pin" the golang builder images to a specific sha256 (which is also architecture specific)? For the golang image, a simple fix for me is to change the image golang:1.21.6@sha256:7b575fe0d9c2e01553b04d9de8ffea6d35ca3ab3380d2a8db2acc8f0f1519a53 to just golang:1.21.6 (or golang:1.22.0), since the golang is multiarch [1] . Would this be acceptable or do you have any concerns?

There is also an issue with the gcr.io/trillian-opensource-ci/ctfe docker image which I believe is not multiarch and would have to be rebuilt as multiarch:

$ docker run -t -i --name tr gcr.io/trillian-opensource-ci/ctfe /bin/bash
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
F0222 16:32:34.005450       1 main.go:115] Failed to read config: open : no such file or directory
prebid-server$ cd ~/gh/sigstore/fulcio/

Slack discussion: https://sigstore.slack.com/archives/C01PZKDL4DP/p1708615569583539

[1] https://hub.docker.com/_/golang -> Quick reference (cont.) -> Supported architectures

[haydentherapper]

Can we select an image based on the architecture docker-compose is run on? Pinning is a good practice as tags are mutable.

cc @cpanato