Support CGO cross building in docker container

[Stebalien]

Now that we're using a docker container for builds, it's a lot easier to setup a cross compiler to build binaries with CGO support for macos & 32bit linux.

We can probably just a docker container from https://github.com/techknowlogick/xgo and I have a feeling it'll "just work".

[aschmahmann]

Some motivation for why being able to compile with CGO across our supported platforms (Linux, OS X, Windows) is useful is that it enables kubo (formerly go-ipfs) to be able to support using the variety of code out there that's not written in Go but is exposed via FFI. Not every binary in this repo should need to support CGO building but it should be available.

Some examples I can think of:

• An implementation of the safer SHA-1 implementation SHA1DC https://github.com/cr-marcstevens/sha1collisiondetection
  • Issue in kubo: https://github.com/ipfs/kubo/issues/8703#issuecomment-1155758989
• SQLite or other databases that were not written in Go (e.g. https://github.com/mattn/go-sqlite3 requires CGO, yes there are alternatives but we may find that the ones with FFI bindings perform the best)
  • This has come up a few times scattered throughout the codebase. Here is one where it's considered to use SQLite to store pins rather than a k-v datastore but it's discarded due to CGO. https://github.com/ipfs/kubo/issues/6556#issuecomment-519295207.

• WASM interpreters such as https://github.com/bytecodealliance/wasmtime-go

  • I wrote https://github.com/ipfs/kubo/pull/9016 against wasmtime-go because my understanding from @Stebalien and others more familiar with the WASM ecosystem was that it was likely the most mature implementation. I wouldn't be surprised if something like https://github.com/tetratelabs/wazero turns out to be faster and more efficient given it doesn't rely on CGO but we shouldn't be forced into it.

  A couple other notes here:

  1. Just because we can use CGO it doesn't mean we should. CGO has a performance cost associated with it that might not be present in native Go code, and it has an ecosystem toll in terms of environments that don't support CGO or when dist.ipfs.io builds use different dynamically linked C code than is available in that environment (e.g. CGO vs musl).
  2. However, we should have the option for utilizing CGO if we'd like to especially when the alternative is to forgo a useful feature or settle for something worse
  3. If enough of the kubo community wants builds that do not support CGO I suspect it'll be doable to work with maintainers on how to build plugins or forks that make non-CGO builds doable. That being said IIUC most kubo users operate in environments where CGO support isn't a big problem.