Extend capabilities to include wasm ABI version number

[tsandall]

Today, OPA does not define an ABI version for compiled policies. As a result, users cannot determine (ahead of time) whether wasm compiled policies can be loaded and evaluated by a set of OPAs--they simply have to compile the policies into wasm, distribute the bundles out to the OPAs, and hope that those OPAs can load the bundles and run evaluation.

Users should be able to determine, ahead of time, whether a set of OPAs will be able to load wasm compiled policies. Today, users can determine whether a set of OPAs will be able to load .rego files by compiling w/ the minimum set of capabilities for the OPAs. E.g., if users know the versions of their OPAs they can pick the capabilities for the oldest OPA version and parse and compile for that version. If we extend the capabilities structure to include a supported ABI version (or set of supported ABI versions) then callers could use the same structure to validate ahead of time that the wasm compiled policies will be successfully loaded by the OPAs.

To implement this feature we need to extend the capabilities structure to include a set of supported wasm ABI versions, e.g:

{
  "builtins": [ ... ] // collection of supported built-ins and type signatures
  "wasm_abi_versions": [ 1, 2 ] // indicates versions 1 and 2 of the ABI can be executed by OPAs with these capabilities
}

For now, we don't have to worry about guaranteeing backwards compatibility on the ABIs.

Internally, the wasm compiler backend will define the ABI version that it supports. When policies are compiled into wasm, the caller can optionally provide the capabilities structure. If the wasm backend's ABI version is not in the set of supported versions, the wasm backend will return an error to the caller:

import "github.com/open-policy-agent/opa/compile"

func main() {
  err := compile.New().
    WithOutput("path/to/bundle.tar.gz").
    WithTarget("wasm").
    WithCapabilities("<minimum capabilities>").
    Build()
}

This is similar to how the built-in function capabilities work on the ast.Compiler.

Similarly, the wasm compiler backend can embed the ABI version into the emitted wasm module and consumers like OPA can determine whether the wasm module is supported.

[srenatus]

On the WASM side, I'd consider the proxy spec for "how do others do it?": its ABI versioning is explained here, where the vNext spec explains

Considered alternatives: Ideally, this would be exported as a global variable, but existing toolchains have trouble with that (some don’t support global variables at all, some incorrectly export language-specific and not Wasm-generic variables).

So, I think since we have good control over the Wasm code we generate, I'll first try to go with the mentioned (immutable) global.

It doesn't seem to difficult to retrieve this using go-wasmtime, see https://pkg.go.dev/github.com/bytecodealliance/wasmtime-go#Global.