esm: refactor responseURL handling

[guybedford]

Refactors responseURL handling solving the same issue as #43130 but with the architecture changes to responseURL as discussed in that PR by treating the module wrap, translators, parentUrl in resolution and providers URLs as the responseURL, as opposed to the module map URL, the resolved URL and the first argument to load as the initial URL. This is consistent with web specifications and gives the correct relative resolution, import.meta.url etc without further function calls being necessary.

In addition this exposes the responseURL return value to the load hook, which is optional. This is landing as treating that as an undocumented loader API for now, since it's generally not an encouraged pattern but is needed by the core loader piping. Whether it should be a public API is a question for the loaders design more generally.

@nodejs/modules @nodejs/loaders

[nodejs-github-bot]

Review requested:

• @nodejs/modules
• @nodejs/vm

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44135/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44200/

[JakobJingleheimer]

Huzzah! Thank you for handling this. A couple nits and a possible naming thing, nothing big 😁

I see you removed the fetch cache check: could you add a test case to test/es-module/test-esm-loader-http-imports.mjs to ensure only the 1 fetch happens? (I can do if you prefer)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44324/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44344/

[guybedford]

Landed in dfa896f.

[danielleadams]

This didn't land cleanly in v18.x (maybe related to #42623 or the work mentioned here #43385 (comment)), so adding a backport-blocked label.

[guybedford]

@danielleadams yes, this should land after #43130, which in turn should land after #42623.