Skip golang-fips hkdf-expandlabel-read patch in FIPS Go build

The ubi-go toolchain applies golang-fips 005-hkdf-expandlabel-read.patch, which panics crypto/tls when the OpenSSL backend cannot derive the exact HKDF-Expand-Label output length. TLS 1.3 derives a 12-byte AEAD IV through that path, and the OpenSSL FIPS provider rejects a derivation that short. Every FIPS binary built with this toolchain therefore dies on its first TLS 1.3 handshake on a FIPS-enabled host. Reported against GitLab Runner as #39707.

• Delete the patch in dockerfiles/ci/Dockerfile.go before full-initialize-repo.sh applies the set, alongside the existing 001-fix-linkage.patch removal.
• Deleted by name glob, because the patch number differs across golang-fips tags (005 on go1.26.3 through go1.26.7). Plain rm, not rm -f, fails the build once a tag stops shipping the patch.
• Reinstates the HKDF performance regression the patch fixed (OCPBUGS-79679) in exchange for a working handshake. This is the same tradeoff taken for the Omnibus FIPS Go toolchain in gitlab-omnibus-builder!491.
• build-mr:images compiles the toolchain on this MR, so a non-matching glob or a broken patch set fails before merge.

Affected images

golang and ubi-go, and every FIPS artifact built from them: the GitLab Runner runner-bin-fips and helper-bin-fips binaries, the ubi-fips runner and helper images, and the downstream OpenShift images that repackage those binaries.

Panic and trigger conditions

time="..." level=info msg="FIPS mode is enabled. Using an external SSL library."
panic: tls: HKDF-Expand-Label invocation failed unexpectedly

goroutine 55 [running]:
crypto/tls.expandLabel(...)
	/usr/local/go/src/crypto/tls/key_schedule.go:294 +0x319
crypto/tls.(*cipherSuiteTLS13).trafficKey(...)
	/usr/local/go/src/crypto/tls/key_schedule.go:33 +0xfa

The patched expandLabel only takes the OpenSSL path when boring.Enabled() is true, which requires GOLANG_FIPS=1 or /proc/sys/crypto/fips_enabled set to 1. CI hosts are not in FIPS mode, so the panic path is unreachable in the pipelines that build these images, and the defect reached four GitLab Runner minor releases undetected.

After merge

This MR only changes how ubi-go is built. Nothing reaches a GitLab Runner artifact until a tag republishes the image and Runner repoints at it.

1. This MR merges.
2. base-images is tagged v0.0.50, which builds and publishes ubi-go:0.0.50. The tag is the delivery step; 0.0.50 is 0.0.49 minus the patch. Tracked in base-images#13.
3. Four Runner MRs, all in Draft and blocked on that tag, come out of Draft and merge: !7281 for main, and !7282, !7283, !7284 for the 19.3, 19.2 and 19.1 stable branches.

All released 19.x FIPS artifacts carry the defect, so all four branches need the bump.

Follow-ups

Deliberately out of scope here, worth their own issues: pinning the golang-fips/go clone to a commit SHA rather than a branch name, so the toolchain in a given ubi-go tag is reproducible; and a GOLANG_FIPS=1 TLS 1.3 handshake smoke test, so this class of defect fails a pipeline instead of a customer upgrade.