Fuzzer: Remove --emit-js-shell logic and reuse fuzz_shell.js instead

[kripken]

We had two JS files that could run a wasm file for fuzzing purposes:

1. --emit-js-shell, which emitted a custom JS file that runs the wasm.
2. scripts/fuzz_shell.js, which was a generic file that did the same.

Both of those load the wasm and then call the exports in order and print out
logging as it goes of their return values (if any), exceptions, etc. Then the
fuzzer compares that output to running the same wasm in another VM, etc. The
difference is that one was custom for the wasm file, and one was generic. Aside
from that they are similar and duplicated a bunch of code.

This PR improves things by removing 1 and using 2 in all places, that is, we
now use the generic file everywhere.

I believe we added 1 because we thought a generic file can't do all the
things we need, like know the order of exports and the types of return values,
but in practice there are ways to do those things: The exports are in fact
in the proper order (JS order of iteration is deterministic, thankfully), and
for the type we don't want to print type internals anyhow since that would
limit fuzzing --closed-world. We do need to be careful with types in JS (see
notes in the PR about the type of null) but it's not too bad. As for the types
of params, it's fine to pass in null for them all anyhow (null converts to a
number or a reference without error).

There are two risks here:

1. Out of tree users of --emit-js-shell. I'm not aware of any myself.
2. If new requirements show up later that force us to use more than generic JS.
   In that case we'd need to write some new code, but it could still be better
   than the status quo - we could at least build on top of fuzz_shell.js rather
   than duplicate it.

[aheejin]

I'm not familiar with the whole history, but it looks nice simplification!

[aheejin]

What does sending a null for a parameter mean? Does this mean the null arg in

func.apply(null, args);

?

I'm not very familiar with JS still, so I looked it up (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply), and it looks the first param is thisArg. Do we need this arg? What does converting this to a number/reference mean?

[kripken]

Ah, yeah, this could be confusing because null is used in two ways. Yes, the first null is thisArg, which we have to pass only because we are using .apply. Basically we want to do

func(null, null);
func(null, null, null);

for a function with two or three parameters, etc. To do that we want to send a vector of arguments, which means we need to use apply, which forces us to provide something for thisArg. The value there doesn't matter.

The nulls that we pass in to the params get converted into wasm types. Sending null to an i32 param gives a 0, and to a (ref null any) gives (ref.null any) and so forth. The specific values don't matter (though it would be nice eventually to send in more values than 0, but the fuzzer added calls inside the wasm with such things). But we do not want to trap because of a conversion, which would happen if we passed 0 because that can't be converted to a (ref null any) for example.

[aheejin]

I see, thanks!

[tlively]

Do we care about supporting non-nullable reference parameters?

[kripken]

In calls from JS I'd say no - we don't have a good way to construct those atm. As mentioned above the fuzzer generates internal calls to exports which gives internal coverage for such functions at least (but not for the JS-wasm boundary, which maybe some day will be important here).

[aheejin]

I see, thanks!