feat: Replace CGO_ENABLED=0 with //go:build ignore

[timraymond]

It will soon become necessary to enable CGO in builds in order to use the MS Go distribution. Disabling CGO was always somewhat of a hack since we didn't need it anyway for eBPF. Now that we do, another solution is necessary. This uses the //go:build ignore directive to exclude all C source files from the Go toolchain. This is necessary even within C source files even though these C source files exist within an underscore-prefixed directory. Go's behavior here is likely erroneous, and an issue has been filed for its repair:
golang/go#69639

[rbtr]

does this change anything wrt the produced binary now being dynamically vs statically linked and needing a libc in our final image?

[timraymond]

@rbtr I had wondered the same, but my testing in KIND of the images produced was successful. I would like to see the windows images functioning, but I currently lack a handy environment to test them.

[timraymond]

So @rbtr, through rebuilding retina images via other means, I think we end up with a libc one way or another by virtue of the fact that we bundle clang and friends in the final images. I'm not 100% on that theory, so I'm still going to let e2es in the merge queue be the final judge of this.

[timraymond]

Looks like E2Es failed on operator due to timeout. It's possible that this is an actual issue, but I'll try again to confirm it.

[rbtr]

So @rbtr, through rebuilding retina images via other means, I think we end up with a libc one way or another by virtue of the fact that we bundle clang and friends in the final images. I'm not 100% on that theory, so I'm still going to let e2es in the merge queue be the final judge of this.

We definitely have them, I'm specifically interested in whether this now means that the Go bins are dynamic and need them

[timraymond]

@rbtr I experimented and found that the answer is yes: we take a dependency on libc with this change.

With CGO_ENABLED=1 (the paths are odd because I built it in nix):

$  ldd result/bin/retina-agent
        linux-vdso.so.1 (0x00007ffff6d27000)
        libresolv.so.2 => /nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libresolv.so.2 (0x00007f698f617000)
        libpthread.so.0 => /nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libpthread.so.0 (0x00007f698f612000)
        libdl.so.2 => /nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libdl.so.2 (0x00007f698f60d000)
        libc.so.6 => /nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libc.so.6 (0x00007f698f420000)
        /nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/ld-linux-x86-64.so.2 => /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007f698f62a000)

Currently (CGO_ENABLED=0):

$  ldd result/bin/retina-agent
        not a dynamic executable

[timraymond]

Operator failed to start in successive runs of E2Es. Upon further investigation locally, this was a result of exec reporting that /retina-operator did not exist. Confusingly, that executable did exist when unpacking the image tarball. After more research into execve, it also throws ENOENT when any of the libraries the executable that is being run are also not found. In this case, and as mentioned previously, we now depend on glibc, which was not present in the retina-operator final image. The solution is to copy in glibc like we do with retina-agent. See details in 2a94fbb .