Improve --target=wasm experience when runtime not supported

[anderseknert]

Expected Behavior

Running opa eval --target=wasm '1+1' should either evaluate or tell the user what it needs to do to get it working.

Actual Behavior

Trace emitted and no instructions provided.

$ opa eval --target=wasm '1+1'
panic: WebAssembly runtime not supported in this build

goroutine 1 [running]:
github.com/open-policy-agent/opa/internal/rego/opa.New(...)
	github.com/open-policy-agent/opa/internal/rego/opa/nop.go:32
github.com/open-policy-agent/opa/rego.(*Rego).PrepareForEval(0xc00031a500, 0x1b1fa50, 0xc00003a0b0, 0x0, 0x0, 0x0, 0x1, 0x203a910, 0x0, 0x0)
	github.com/open-policy-agent/opa/rego/rego.go:1459 +0xbe5
github.com/open-policy-agent/opa/cmd.eval(0xc0001c0680, 0x1, 0x2, 0x0, 0xc0001ba7c0, 0x1, 0x1, 0x203a910, 0x0, 0x0, ...)
	github.com/open-policy-agent/opa/cmd/eval.go:284 +0x9f5
github.com/open-policy-agent/opa/cmd.init.4.func2(0xc0001ef180, 0xc0001c0680, 0x1, 0x2)
	github.com/open-policy-agent/opa/cmd/eval.go:220 +0xcf
github.com/spf13/cobra.(*Command).execute(0xc0001ef180, 0xc0001c0660, 0x2, 0x2, 0xc0001ef180, 0xc0001c0660)
	github.com/spf13/cobra@v0.0.3/command.go:766 +0x2c2
github.com/spf13/cobra.(*Command).ExecuteC(0x1ff5900, 0xc000000180, 0xc000237f78, 0x1007e45)
	github.com/spf13/cobra@v0.0.3/command.go:852 +0x2fe
github.com/spf13/cobra.(*Command).Execute(...)
	github.com/spf13/cobra@v0.0.3/command.go:800
main.main()
	github.com/open-policy-agent/opa/main.go:15 +0x31

Additional Info

Someone with better insight into the problem suggested the following options:

1. Update the nop implementation of the OPA SDK to not panic. Instead functions that don't return an error can simply be nops and functions that do return an error can return a useful error message.
2. Since we don't have to distribute the wasm runtime shared library anymore (because the wasmtime runtime is statically linked), we can ship OPA executables that include it. To do this we need to tinker w/ the OPA build.
3. If after (2) someone manages to get an OPA executable built that doesn't include the wasm runtime, it should just return an error that says what it does today w/ an additional bit like "go to releases ..."

[srenatus]

Since we don't have to distribute the wasm runtime shared library anymore (because the wasmtime runtime is statically linked), we can ship OPA executables that include it. To do this we need to tinker w/ the OPA build.

I think this is worth considering! The problematic bit, I think, is the use of cgo. Its cross-build story is "don't", they advise to always build natively. So, to build macos and windows binaries with Wasm enabled, we'd need to get those OSes into our release build runners, see also #3176.

[tsandall]

@srenatus I was hoping that cross-compiling w/ CGO wouldn't be so bad if we created our own Docker image that had the toolchains for darwin and windows installed. Is that not the case? If so, I agree we should probably just not panic and improve the error message a bit and then close this. I don't want to overcomplicate the build for this feature at this point in time.

[srenatus]

@tsandall I might just be having old (anec)data, let's try and find out. :)

[srenatus]

Fixed the error message for people still managing to build without wasm in #3416 ☝️