feat(ses,module-source): Add ModuleSource shim

[kriskowal]

Refs: #2252

Description

To test feature the degree of compatibility between a version of XS, XS with Endo shims, and Node.js with Endo shims, we need a shim for ModuleSource proper. This lets us create an environment with a global ModuleSource, where ModuleSource is a shared intrinsic of all Compartments.

This change both introduces the shim and the necessary accommodations for the existence of a global ModuleSource shared intrinsic in SES.

Security Considerations

The new ModuleSource is subject to hardening of shared intrinsics during SES lockdown. A failure to harden the shared intrinsic would lead to a potential for interference or communication between isolated compartments.

Scaling Considerations

None.

Documentation Considerations

None.

Testing Considerations

This includes a test for SES that verifies that ModuleSource is properly propagated and hardened.

Compatibility Considerations

None.

Upgrade Considerations

None.

[kriskowal]

A valid but annoying feedback reviewers might provide here is that we can’t anticipate whether ModuleSource will land in the language with or without an AbstractModuleSource on its prototype chain, so we could hedge our bets and add a repair for ModuleSource to force it to appear one way or the other, so that lockdown() doesn’t break if the AbstractModuleSource is absent. Or, we could go the other way and not have AbstractModuleSource by default, in which case SES would just delete it and issue a warning if it showed up.

[gibson042]

You read my mind, but that's just the risk with front-running proposals. No suggestion.

[kriskowal]

Capturing here my reasoning for keeping AbstractModuleSource since it appears to be the path of least regret.

1. We shim AbstractModuleSource and include it in SES permits:
   1. The application includes module-source/shim.js:
      1. The VM implements AbstractModuleSource: ✅ Lockdown’s fine
      2. The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine. The shim currently stomps the native implementation. If it didn’t stomp the native implementation, Lockdown would tolerate the incomplete intrinsics.
   2. The application excludes module-source/shim.js:
      1. The VM implements AbstractModuleSource: ✅ Lockdown’s fine
      2. The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine, but intrinsics are incomplete
2. We do not shim AbstractModuleSource and exclude it in SES permits:
   1. The application includes module-source/shim.js:
      1. The VM implements AbstractModuleSource: ✅ :man-shrugging: The shim currently stomps the native implementation, so this works out. But, if the shim surfaced the native implementation (and perhaps feature-checks that the native implementation behaves just like the shim deigning to fall through to native)
      2. The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine
   2. The application excludes module-source/shim.js:
      1. The VM implements AbstractModuleSource: 💔 Lockdown is surprised to find AbstractModuleSource and chooses throw rather than attempt a repair. We don’t have the module source shim in play, so there’s nothing it can do to mitigate. We can’t require the module-source/shim.js because it entrains Babel.
      2. The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine