Refactor image build and release

What does this MR do and why?

Use docker buildx bake

We're tagging a lot of versions here:

• Major, minor, and patch versions for the public registry.
• Major, minor, and patch versions for the private registry.
• A temporary image that is tied to a commit. This allows us to test how the analyzer works in a different project.

We've done in the past with bash scripting, but it's a bit cumbersome to do. In the spirit of avoiding shell scripting, I've moved all of this logic to a docker-bake.hcl file. It's easier to reason about, and we're able to do dry runs for a target by doing things like:

docker buildx bake --print public

That said, I still needed a small wrapper to set up some of the variables used to build the image. These things include the created timestamp, the project and repository url, and the revision checked out when building the image.

Releasing a temp image per MR commit

While testing this project, I found myself having a hard time sharing the image across other projects without manually doing it myself. With cleanup policies, we should be able to have the convenience of having these temp images, and not have to worry about cluttering the registry.

Addition of the release to the public registry

I've updated the release job to push an image to the public registry as well, so that we can point to the major version in the CI/CD component.

Builder image forced to linux/amd64

The registry.gitlab.com/gitlab-org/gitlab-runner/go-fips:1.22.5 is only available for linux/amd64 since it's not a multi-arch build, so it's hardcoded to avoid trying to pull a non-existing variant.

Hardcoding the platform causes a build check FromPlatformFlagConstDisallowed warning unless the stage name includes the OS or architecture name, hence the change to linux-amd64-builder.

TODO: the container scanning job isn't working

We should fix this. I think we'll need something like the following:

1. Run the CS job after the release stage in another stage. Maybe artifact scanning?
2. If not a tag pipeline, set the CS_IMAGE to ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}
3. If tag pipeline, set this to the release version instead ${CI_REGISTRY_IMAGE}:${RELEASE_VERSION}

I think this will populate the vulnerability dashboard, and the MR widget.

Related issues

This is a prerequisite for Create Dependency Scanning CI/CD Component (gitlab-org/gitlab#433267 - closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.