Added browser tests using wasmtime test artifacts

[jsoverson]

This PR adds the start of browser-based tests. It adds a playwright configuration to test across Firefox, Chromium, and Webkit and uses test artifacts from the wasmtime project to assert compatibility.

Only one test has been added so far (test-programs/preview1_path_open_read_write). It required some project changes that need review before moving forward.

To run tests:

$ npm install
$ npm run test:build  # clone wasmtime and compile test .wasm
$ npm run build       # compile project typescript
$ npm run test        # run tests

Change Notes:

• The initialize() function was updated to only call _initialize() if it's exported. AFAICT _initialize() is optional. This lets all reactor libraries use the same shim init logic without needing the user to inspect the exports.
• I had to pull the wasiImport types into a proper interface to keep satisfying TypeScript. This had the side effect of requiring some changes to satisfy types that would have been the source of errors before. Any change where obj[key] = undefined becomes delete obj[key] is due to this. (reverted)
• I needed to propagate the rights flags through to the Fd implementations so that fd_fdstat_get could report correct values.
• I added a dumb path_unlink_file implementation to Dir to satisfy the test wasm. It deletes the instance from the dir's contents and doesn't do anything more destructive.

[jsoverson]

@bjorn3 I hope these changes are again in the right direction. Testing could go any one of a dozen ways, and this seemed like the best cost/value.

[bjorn3]

Using wasmtime's wasi tests is a great idea. Thanks for working on this. FYI I probably won't have time to review this in the next couple of days.

Part of #7

[jsoverson]

@bjorn3 np, thanks for being willing and responsive!

[bjorn3]

nit: missing trailing newline

[bjorn3]

Could you add a FIXME to check if the path actually exists and to return an error otherwise. Also is there no test in wasmtime's test suite for that?

[bjorn3]

Would making RIGHTS_FD_WRITE a Bigint work to avoid this cast?

[bjorn3]

For please use {} for if where the action is not on the same line. That helps prevent issues like the duplicate "goto fail;" that caused a huge security issue in macOS a couple of years back.

[bjorn3]

Are the submodules actually necessary? And if so are all of them necessary?

[bjorn3]

Could you pin a specific commit of wasmtime for reproducibility in the future?

[bjorn3]

Suggested change

	TARGET_DIR=$(ls -dt $WASMTIME_DIR/target/debug/build/test-programs-artifacts-* | head -n 1)
	TARGET_DIR=$(ls -dt $WASMTIME_DIR/target/debug/build/test-programs-artifacts-*/out | head -n 1)

There is no guarantee that the first one is the one with the OUT_DIR.

[bjorn3]

I'm not entirely sure all fs_rights_base changes are correct. Would you mind pulling out all changes to the actual code except for fs_rights_base into a separate PR? Also could you add CI integration?

[bjorn3]

@jsoverson are you still interested in working on this or would you prefer if I work on splitting it up into several commits and landing it myself?

[jsoverson]

@bjorn3 sorry, this fell off my radar during a few hectic weeks. I'll jump on it this coming week.

[jsoverson]

Status: I'm going to fork wasmtime to create releases consisting of strictly the test wasm files. Getting CI setup to clone wasmtime to build the test artifacts is excessive.

[bjorn3]

You can use --filter=blob:none when cloning to tell git to only fetch the blobs that are actually necessary. For me that only takes 10s for a total download of 24MB. It can be reduced even further using a sparse checkout, but I think 10s is more than fast enough.

[jsoverson]

It's more the overhead of setting up a rust environment to build wasm files that really shouldn't change. It will dramatically extend the duration of CI tests, vs. downloading a tarball of wasm artifacts.

[bjorn3]

I see. How about caching the wasm test files in a github actions cache after they are built. And then only setup a rust toolchain for building if the cache is missing. That should be easier to keep up to date with new wasmtime versions than building locally and checking into a repo.