fix: Add CGO_ENABLED=0 flag to Dataflow example

[damondouglas]

Description

Fixes #4405 by adding CGO_ENABLED=0 to build instruction of Dataflow example.

Checklist

• I have followed Contributing Guidelines from CONTRIBUTING.MD
• Tests pass via https://cloud.google.com/dataflow/docs/guides/templates/using-flex-templates
  Tests pass: go test -v ./.. (see Testing)
  - [x] Code formatted: gofmt (see Formatting)
  - [ ] Vetting pass: go vet (see Formatting)
  These samples need a new API enabled in testing projects to pass (let us know which ones)
  These samples need a new/updated env vars in testing projects set to pass (let us know which ones)
  This sample adds a new sample directory, and I updated the CODEOWNERS file with the codeowners for this sample
  This sample adds a new Product API, and I updated the Blunderbuss issue/PR auto-assigner with the codeowners for this sample
• Please merge this PR for me once it is approved

[iennae]

@damondouglas can you provide a bit more context on this change?

This disables the mechanism for working with c code which might be the right path if no c libraries are needed, and the reason it's failing in some places might be due to the different environments (containers or on a mac where glibc libraries aren't available). I'm a little worried this might cause a potential issue based on assumptions about where users might run the code. I haven't dug into the existing code to verify what is needed so if you can give some feedback on the context that would be reassuring to merge this.

[davidcavazos]

I'm not too familiar with the Go compilation process and how Cgo affects it. From a quick search, it looks like Cgo allows access to C's stdlib in the target environment, which is useful in some targets like Android. This, however, introduces stdlib as a dynamically linked library, so the resulting Go binary is no longer statically isolated (one of the best features of Go). From some reading, it looks like if Cgo is enabled, it'll use stdlib functions, but if it's disabled then the Go compiler introduces its own versions of those functions and keeps the binary completely independent from the host system.

Here's a great blog post that goes into some more detail.

From what I can gather, this is not only safe, but will guarantee consistent binaries that don't depend on the system stdlib (which can be different on different operating systems and Docker images like alpine). I'm actually a bit surprised that Cgo is enabled by default, it would seem like a feature that should be opt-in only if you need it. It is (inconsistently) disabled by default when cross-compiling.