Explore wasmtime for the autosplitters

[CryZe]

We haven't entirely settled on wasmer yet and it has some flaws that haven't been resolved yet. wasmtime now implements some of the things we definitely need, such as the ability to terminate execution at will, which is important as otherwise a faulty autosplitter could consume 100% of some thread as it gets stuck in some infinite loop and you couldn't do anything about it.

[CryZe]

Seems like wasmtime doesn't work on Windows currently. Here's the tracking issue:
bytecodealliance/wasmtime#1587

[CryZe]

I was able to verify that my port works at all with a modified fork. Unfortunately I was not able to test interrupting the execution, because cherry picking that commit causes too many conflicts. So I guess we'll have to wait on this properly being fixed upstream. In the meantime we can do other fixes on the branch (like pulling in kithlith's changes and enabling WASI), but it certainly seems like we'll stick to wasmtime.

[CryZe]

Okay, so it seems like their WASI implementation is far from ideal. There's various unimplemented functions that just panic the host process (though possibly wasmtime might catch that unwind?). However at least proc_exit is really problematic as it just straight up unconditionally stops the host process. Additionally there seems to not really be a way to override stdin / out / err other than choosing a different host file. It generally has a notion of virtual files, but not for those.

I might be able to send a few PRs for some of these problems.

[CryZe]

I was able to locally modify their WASI implementation and created some tests that ensure:

• That an empty "hello world" works
• That writing to stdout is properly captured and forwarded to the logs
• That segfaulting is properly sandboxed and shuts down runtime without causing problems for the host
• That creating a file (or really accessing any files) is impossible from an auto splitter.
• That exiting the process from an auto splitter shuts down the execution of the script, not the host.

I still need to add tests for env vars, command line arguments and networking (which are the unimplemented methods, what happens then?).

[CryZe]

Alright, so command line arguments are empty as expected. Environment variables are empty, can be set, but are independent from the host. Threads don't work as expected. Time Stamps can be taken. Random numbers work as well. However there's one thing that I'm not quite sure how to deal with yet, as it's quite complicated and that's poll_oneoff. It allows blocking on various files with a timeout. It's also what is being used for std::thread::sleep. This both allows sleeping forever and blocking on files that may also never have any new data. There's no way for the host to break out of this. Additionally the implementation seems quite bad atm, as polling a virtual file (which the script can't even differentiate as it lives entirely within this virtual OS) completely panics on the host side. There's not much I can do here other than raising an upstream issue.

[sunfishcode]

FYI, concerning the proc_exit issue mentioned above, bytecodealliance/wasmtime#1646 has a fix for that, so it no longer exits the host process.