build: WASM_ENABLED=1 for all platforms

[srenatus]

Notes:

• If there are other users of the 'build-windows' make target they would
  likely be annoyed by the change that's now apt-get'ting packages

• We could build a builder image instead of installing the package every
  time.

• ci-go-*: run as root now, so we're able to install the packages for
  windows.

• tests: skip tests that depend on not being run as root when root. The
  change to ci-go-* makes that necessary; the impact is rather limited
  right now. We can reconsider if there are more tests depending on not
  being run as root.

• build: add '-buildmode=exe' to GOFLAGS

  Primarily for the windows build, but I don't think it should be wrong
  for the others either:

  cmd/link: "x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large" after upgrading to Go 1.15 golang/go#40795

  See https://golang.org/cmd/go/#hdr-Build_modes:

  -buildmode=exe
  Build the listed main packages and everything they import into
  executables. Packages not named main are ignored.

• go: bump to 1.16.3, keep compat with 1.15

  See https://golang.org/ref/mod#go-mod-file-go about the go directive in
  go.mod:

  A go directive indicates that a module was written assuming the semantics
  of a given version of Go.

• build: update go module related env vars

  With 1.16, https://blog.golang.org/go116-module-changes,

  The go command now builds packages in module-aware mode by default.

  Also, since we've added the go 1.15 directive to go.mod, we can drop
  all -mod=vendor flags, https://golang.org/ref/mod#go-mod-file-go,

  At go 1.14 or higher, automatic vendoring may be enabled. If the file
  vendor/modules.txt is present and consistent with go.mod, there is no
  need to explicitly use the -mod=vendor flag.

• build: replace build-docker by build-linux

  Turns out the binaries were identical now.

• workflow: adapt github workflows

• build: override docker id/gid in 'image' target, to keep existing
  behaviour.

---

References:

1. https://dh1tw.de/2019/12/cross-compiling-golang-cgo-projects/
2. Improve --target=wasm experience when runtime not supported #3264: if all our release binaries have wasm enabled, much less people will run into the panic.

[tsandall]

Just questions.

[srenatus]

Some notes

[srenatus]

👉 https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on

macos-latest is 10.15, not big sur. But the binaries work on the latter, too.

[srenatus]

Downloading the gcc for mingw32 on the fly still lets the linux+windows build finish under 3 minutes. I'd say we look into a builder image if this proves to be brittle or annoying.

[tsandall]

Downloading the gcc for mingw32 on the fly still lets the linux+windows build finish under 3 minutes. I'd say we look into a builder image if this proves to be brittle or annoying.

I guess as long as no one is using build-windows in their dev environment, that's fine.

[srenatus]

Squashed and ready to go. 🏁

[srenatus]

Splitting the Linux/Windows build doesn't make a huge difference, but it won't hurt, I think:

Before

After

☝️ The feedback for build/linux and npm-opa-wasm will be a bit quicker. 🚤

[tsandall]

Just for my own understanding...whereas before we would build the OPA binaries here, now they will be built above by release-build and release-build-darwin and then downloaded here. Is that correct?

[srenatus]

Yup!

[srenatus]

This was approved, and rebased -- will squash and merge when green.

[srenatus]

This PR had a spurious "waiting for status to be reported" right from the start, but it's actually all green now: https://github.com/open-policy-agent/opa/actions/runs/813799167