Replace bulk of wasmtime-wasi with wasi-common

[kubkon]

This is a rather big set of changes so I'd rather take it step a time and thoroughly discuss before simply just merging it in (even if it's to a non-master branch).

The PR touches wasmtime-wasi and wasmtime.rs, and features:

• completely removes sandboxed-system-primitives and any dependence on bindgen
• all hostcalls are (or will be) provided by wasi-common external crate
• currently relies on wasi-common#missing-hostcalls branch but only until that one will be merged into master (Add stubs for unimplemented hostcalls CraneStation/wasi-common#7)
• it doesn't deal with JS polyfill just yet
• does a few nasty unwrap()s but these will be cleaned as the discussion progresses

EDIT: add initial todo

TODO:

• clean up unwrap() calls
• update to master branch in wasi-common
• handle alignment check in decode_ptr

[kubkon]

I'm curious to see what you reckon about all this @sunfishcode

[kubkon]

I've also had to update the minimum Rust version to 1.34+ as required by wasi-common (see CraneStation/wasi-common#11).

[sunfishcode]

Overall this looks good. We can figure out how to handle the js-polyfill later.

One of the changes here is that syscalls.rs no longer does wasm32<->host translation. wasi-common's APIs all use wasm32 types. I was initially concerned about this, however I'm starting to see a new way that things could work here. The majority of WASI types use fixed-size types like u32 and u64 or structs thereof, and are actually the same between the two. In fact, only __wasi_prestat_t, __wasi_iovec_t, and __wasi_ciovec_t are the only types that are about pointer/usize size.

So my idea now is that we can eventually move much of wasm32.rs and host.rs into a common file, and make the translation between the two simpler. But that doesn't need to happen right away.

[sunfishcode]

Can you move this TODO comment into wasi-common?

[kubkon]

Done in CraneStation/wasi-common#14 :-)

[kubkon]

Overall this looks good. We can figure out how to handle the js-polyfill later.

One of the changes here is that syscalls.rs no longer does wasm32<->host translation. wasi-common's APIs all use wasm32 types. I was initially concerned about this, however I'm starting to see a new way that things could work here. The majority of WASI types use fixed-size types like u32 and u64 or structs thereof, and are actually the same between the two. In fact, only __wasi_prestat_t, __wasi_iovec_t, and __wasi_ciovec_t are the only types that are about pointer/usize size.

So my idea now is that we can eventually move much of wasm32.rs and host.rs into a common file, and make the translation between the two simpler. But that doesn't need to happen right away.

That's an interesting idea. So how would you ideally see wasi-common hostcalls: accepting wasm32 types or rather actual host types? If the latter, then I guess implementors would then need to worry about the translation wasm32<->host as you pointed. The downside is that the implementors would have to do this rather than just call the hostcall from the lib.