vm: sync-ify SourceTextModule linkage

[legendecas]

Split module.link(linker) into two synchronous step
sourceTextModule.linkRequestedModules() and
sourceTextModule.instantiate(). This allows creating vm modules and
resolving the dependencies in a complete synchronous procedure.

This also makes syntheticModule.link() redundant. The link step for a
SyntheticModule is no-op and is already taken care in the constructor
by initializing the binding slots with the given export names.

This also enables (static) source phase import in vm.SourceTextModules.

Refs: #37648

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/vm

[codecov]

Codecov Report

Attention: Patch coverage is 78.18182% with 12 lines in your changes missing coverage. Please review.

Project coverage is 90.07%. Comparing base (4de0197) to head (9c18d11).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/vm/module.js	76.31%	8 Missing and 1 partial ⚠️
src/module_wrap.cc	78.57%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #59000      +/-   ##
==========================================
+ Coverage   90.04%   90.07%   +0.03%     
==========================================
  Files         641      641              
  Lines      188846   188898      +52     
  Branches    37039    37052      +13     
==========================================
+ Hits       170040   170151     +111     
+ Misses      11504    11453      -51     
+ Partials     7302     7294       -8     

Files with missing lines	Coverage Δ
lib/internal/errors.js	97.50% <100.00%> (+<0.01%)	⬆️
src/module_wrap.h	44.44% <ø> (ø)
src/node_errors.h	87.50% <ø> (ø)
src/module_wrap.cc	73.66% <78.57%> (+0.50%)	⬆️
lib/internal/vm/module.js	96.24% <76.31%> (-2.15%)	⬇️

... and 39 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[joyeecheung]

Suggested change

	The order of the `modules` array should respect the order of
	[`sourceTextModule.moduleRequests`][].
	The order of the module instances in the `modules` array should correspond to the order of
	[`sourceTextModule.moduleRequests`][] being resolved.

[joyeecheung]

Suggested change

	validateThisInternalField(this, kWrap, 'SyntheticModule');
	validateThisInternalField(this, kWrap, 'SourceTextModule');

[joyeecheung]

I wonder if the separation of two methods is actually necessary? This just stashes the wraps into an internal map. It seems fine to just merge all this into instantiate() and only do the conversion when instantiation happens. Users can maintain an array themselves before calling instantiate() and that doesn't seem to make a whole lot of difference - the map is not really visible to them anyway. In return the API would look simpler and users can be more flexible in how they maintain that array e.g. fill them in a non-consecutive way, or modify them as much as needed.

On a related note, I don't think the resolve cache even strictly has to be in C++ land. The current way of managing the cache using a v8::Global may be leak prone since V8 doesn't necessary know that a specific Module wrap is the only one that holds a bunch others alive - it just sees a bunch of v8::Global "out of nowhere" because V8's GC can't trace what that map is doing in C++ obviously. That might be the cause of #50113 (or that was my conclusion ~2 years ago: #50113 (comment)). Moving the cache to JS land might make it go away since then V8 would be able to understand all the inter-module-wrap references. And if it's in JS land, the linkRequestedModules() isn't strictly necessary because there might be better ways to interact with the cache. It looks more like a design that's specifically tailored to how we currently manage this cache, which is more of a thing that just happened but is not necessarily optimal design-wise.

[legendecas]

It is necessary to split to link and instantiate to support cyclic module requests. Please have a look at test/parallel/test-vm-module-instantiate.js.

[legendecas]

The resolve cache will be cleared immediately when instantiate is invoked. It is only intended to be easily referenced in the ResolveModuleCallback from V8. If a SourceTextModule is correctly invoked with instantiate after linkRequestedModules, the resolve cache should not keep the modules alive indefinitely.

node/src/module_wrap.cc

Lines 615 to 616 in e3e739d

	// clear resolve cache on instantiate
	obj->resolve_cache_.clear();

For #50113, I think an OOM can be reproduced without link or evaluate: #50113 (comment).