Golang: Crypto/fips140: do not bloat crypto code unnecessarily

Proposal argues that the FIPS 140 support recently added to Go’s crypto stack is compiled into nearly every binary regardless of use, unnecessarily increasing code size, memory use, disk footprint, and CPU cost from extra indirection and init-time work. The core complaint is that most users never enable FIPS mode at runtime (it's gated by a default-off GODEBUG flag), yet the code - and its init functions - still lands in builds. The suggested fix is a compile-time option (a new GOFIPS140=disabled default) so unused FIPS code is omitted; in practice that would let an Enabled symbol become a const rather than a var and avoid pulling in large subsystems when not needed.

Concrete effects cited include additional branching and indirection in TLS, RSA/PKCS1, crypto/rand, and AES/GCM paths. The reporter focused on the RNG case, showing a tiny program that imports crypto/rand nonetheless pulls in many crypto/internal/fips140 symbols (AES, GCM, DRBG, HMAC, entropy helpers, asm routines, and multiple init functions), demonstrating real binary bloat. The proposal contends compile-time gating will remove those dead-but-compiled code paths, keeping non-FIPS builds leaner and less complex.