Add WIT equivalent of WITX 0.10 spec

[Robbe-Haegeman]

The following PR introduces the WIT equivalent of the WITX 0.10 specification, aiming to stick as close to the WITX 0.10 version as possible.
I hope this makes the change easier to review by allowing direct comparison to the current spec.

Closes #56

This was partially done through a quick-and-dirty transpiler I wrote using the [witnext](https://crates.io/crates/witnext) and [wit-encoder](https://crates.io/crates/wit-encoder) crates.
An overview of the changes required to move from WITX to WIT, including automatic mapping vs. manual changes, can be found in the README in the WIT directory.

Regressions when compared to the WITX version:

• size: no longer backed by a usize, but a u32 instead.
• options-set-guest-buffer: not possible in WIT to provide guest memory to the host (i.e. it does not count toward the guest's memory budget anymore).
  • Workaround uses a list<u8>, but is marked as deprecated.
  • Serves as a stopgap till [caller-supplied buffers](https://wasi.dev/roadmap) arrive in future WASI 0.3.x release.
• For symmetric-state-encrypt, symmetric-state-encrypt-detached, symmetric-state-decrypt, and symmetric-state-decrypt-detached; the ability to encrypt in-place had to be removed
• version: no longer stored in one u64 but instead as a variant .
• _batch: these make use of out-buffer and in-buffer which are not defined in the WITX files.
  • This was replaced with list<u8>s instead.
  • Some of the types of the parameters also did not line up with the docs/non-batched versions, which was also changed for the WIT adaptation.

The interface is currently not tested on an implementation.
The syntax itself was quickly verified using wasm-tools component wit.
I'm more than happy to try and adapt the wasi-crypto example implementation or try and link to another crypto library, but wanted to discuss this first.
This is also the main reason why this is in draft.

If this PR lands, I propose to make this WIT specification the new source of truth.
To keep this PR manageable, I suggest handling modernizations in follow-up PRs/Zulip discussions.
Examples of this would include:

• moving functions which are linked to specific handles to methods on resources
• removing the use of close functions, using destructors instead
• making use of streams (either wasi/io streams or the ones from wasi 0.3)
• ...

I'm completely open to feedback and happy to make adjustments where needed!
My goal is to help push wasi-crypto further in the standardization process for which I hope this is a good first step :)

[jedisct1]

This is great! Thank you so much for taking this on!

One concern I have is that losing memory-hard key derivation support and in-place encryption/decryption would be significant regressions.

Beyond performance, this will have a major impact on memory usage, requiring twice as much memory as before. That may make it difficult, or even impossible, for some existing applications to move to the new interface as-is.

Given that, I think it may be better to wait for WASI 0.3 restoring caller/guest-supplied buffers before making this the new source of truth. It would also be really valuable to have at least two implementations before we treat the WIT version as authoritative.

Implementing it is often the best way to find out whether the specification is actually implementable and ergonomic, especially outside of Rust.

Maybe this could live in a separate branch for now? That would let us keep exploring the WIT/component-model version while allowing the documentation to stay aligned.

Thanks again! This feels like a really useful step forward.

[Robbe-Haegeman]

My initial suggestion was mostly to get some WIT version out the door to serve as a source of truth (which I would not want to do without it being tested on at least one implementation).

I agree with your observation that some of the regressions would be significant, though I would argue that these shortcomings are not uncommon in current production libraries.
These could be brought back in later releases, once the dependencies stabilize, preventing them from blocking the standardization process.

I'm ok though with moving it to a separate branch for now. That way I have the freedom to make the WIT API more idiomatic, without making review more difficult. Seems especially useful while I'm creating the implementation.
Are you willing to merge the current version to a branch or would you prefer to wait till at least one (or both) of the implementations is/are finished? I'm fine with it either way :)

Since having two implementations is only part of phase 3, I would prefer to focus on a wasmtime implementation currently and use that to bring the interface to a standard we're happy with.
Afterwards, we could have a look at other implementations.

Nevertheless, here is a short rundown of the runtimes I considered:

• wasmtime is a given. The WITX version already supports it and it is the reference implementation for the component model.
• wasmedge? As far as I can tell from this issue only has partial support for the component model.
• jco is the main other option which I see used for WASI proposals. Here the best option seems to be to use web-crypto under the hood. However, I assume that there are cases where it does not provide/expose everything we would need. Another option would be to forego web support entirely and instead only focus on Node.js, which would allow us to use its crypto API. I'm guessing that is probably easier to support.

A lot of the other runtimes seem to either embed wasmtime or have less widespread use, but I could have definitely missed some!

Thanks for the quick response btw!