`handleWasmStreaming` is the function that provides the binding with
the `fetch` API needed for `WebAssembly.instantiateStreaming()` and
`WebAssembly.compileStreaming()`. When I implemented it in #11200, I
thought V8 was calling these functions with the argument of the
`WebAssembly` streaming functions, without doing any resolving, and so
`handleWasmStreaming` awaits for the parameter to resolve. However,
as discovered in
https://github.com/denoland/deno/issues/13917#issuecomment-1065805565,
V8 does in fact resolve the parameter if it's a promise (and handles
rejections arising from that).
This change removes the `async` IIFE inside `handleWasmStreaming`,
letting initial errors be handled synchronously (which will however
not throw synchronously from the `WebAssembly` namespace functions).
Awaiting is still necessary for reading the bytes of the response,
though, and so there is an `async` IIFE for that.
Fetching of local files, added in #12545, returns a response with no
headers, including the `Content-Type` header. This currently makes it
not work with the WebAssembly streaming APIs, which require the response
to have a content type of `application/wasm`.
Since the only way to obtain a `Response` object with a non-empty `url`
field is via `fetch()`, this change changes the content type requirement
to only apply to responses whose url has the `file:` scheme.
The streaming WASM support code inspects the Response object's
Content-Type header but if that was missing, it failed with a fairly
inscrutable "String.prototype.toLowerCase called on null or undefined"
exception. Now it raises a more legible "Invalid WebAssembly content
type" exception.
The WebAssembly streaming APIs used to be enabled, but used to take
buffer sources as their first argument (see #6154 and #7259). This
change re-enables them, requiring a Promise<Response> instead, as well as
enabling asynchronous compilation of WebAssembly modules.
