Track the source of fetching errors in module graphs

[domenic]

From #2991 (comment)

If any of the invocations complete with null, we will get a fetch error, and bail out before "find the first parse error" is reached.

Fetch errors are not given any real "identity"; they are all just null. So at the spec level it doesn't matter if you wait or not; you still get null. In implementations, though, you may want to propagate more useful information. I wonder if we should write that in the spec.

I think this will not be too hard to change. We will just introduce some new struct, a "script fetching error", which contains a URL. Then instead of propagating null we can propagate that through the chain. And this step in particular will be about deterministically finding the right script fetching error.

Finally when we get to "execute the script block" we will check to see if the script's script is a script fetching error, and say that the UA may optionally use the URL in the script fetching error to give good diagnostic info (e.g. in the developer console). At this point we can also rename script's script -> script's result, which is slightly less confusing of a name.

@hiroshige-g also notes that

In the classic script world, "script's script is null" and the fact that onerror is fired is sufficient, because there is only one URL that can fail to be fetched, which is no longer true in module graph loading.

Will do when #2991 is all settled down.

[nyaxt]

Split of fetch errors and script fetching error sounds like a good idea to me.

[nyaxt]

Sorry I misunderstand the point. I'm not sure if this is super useful to web developers.
IIUC, this is only useful when webdev explicitly write error handlers for script tags.
For normal debugging use-cases, the browser developer tools should already provide enough context for the fetch failure.