feat: Introduce a new baseline system.

[jsantell]

We're moving to a different architecture, while still remaining flexible.

ct-engine is the root distributable, encapsulating the logic of sandbox creation/hosting, and (in the future) scheduling and persistence. This produces a JS module and native binary. For now, this is a mostly a TODO and wrapping ct-runtime.

ct-runtime is a simple sandbox creator, and when given a string of a JS module, can run some process in the VM. Under the hood, this uses wasmtime to host the VM on native, and wasm_component_layer for wasm32-unknown-unknown, using the browser's native WASM engine. Yes, WASM components polyfilled in browsers!

ct-js-vm is the wasm component, wrapping the Boa JS engine. The current interface is run(string) -> result<string, string>, or a way to pass in some JSON-parsable string, and return the serialized value of the run export's return value.

The interface looks something like this:

    let source = r#"
    export const run = (input) => {
      input.foo = input.foo + 1;
      return input;
    }
    "#;
    let definition = ModuleDefinition {
        vm: VirtualMachine::JavaScript,
        source: source.into(),
    };

    let runtime = Runtime::new()?;
    let mut module = runtime.module(definition).await?;
    let mut instance = module.instantiate().await?;

    let input = r#"{"foo":9}"#;
    let output = instance.run(input.into()).await?;
    assert_eq!(output, r#"{"foo":10}"#);

• A lot of future cleanups if we want to invest in this.
• The VM interface was designed to be simple to work out the isomorphic sandboxing work, and is expected to change to something else.
• Pivoting; quietly remove/hide previous crates and github actions.
• Boa engine requires wasi:random/random at startup. All other interfaces are stubbed out with wasi-virt.
• Current browser WASM support using forks to satisfy our VM; will work on upstreaming.
  • https://github.com/jsantell/wasm_component_layer
  • https://github.com/jsantell/wasm_runtime_layer