feat(ses,static-module-record): XS variants and parity test infrastructure

[kriskowal]

Refs: #400

Description

This introduces an XS-specific variant on the SES and StaticModuleRecord packages and includes a suite of parity tests for ensuring equivalent behaviors between Node.js and XS.

The compatible flavor of XS is very specific. Endo’s Compartment Mapper provides a Rollup-analogue bundler that respects Node.js’s conditional imports and generates a single script we can run under xst and could use to bootstrap xsnap. To use these XS contingent variants on SES and StaticModuleRecord, we must use Endo’s bundler with the "xs" tag.

Security Considerations

We must take care to ensure that our parity tests cover (or at the very least spot-check) all the security properties of SES.

Scaling Considerations

We expect considerable performance improvement using XS-specific SES shim and ModuleSource variants on XS and other improvements to ecosystem health in general, discussed in #400.

Using an XS-specific variant of SES and StaticModuleRecord makes it possible to even contemplate bundling on XS. The native ModuleSource on XS performs considerably better than Babel on Node.js.

Documentation Considerations

None yet.

Testing Considerations

This change does not yet run these test suites under CI. Further work is needed to bring a specific verison of xst into CI and help developers reproduce that xst version as a local dependency. That may entail a submodule like Agoric SDK.

Compatibility Considerations

This change seeks to adapt the native XS Compartment to the API of the SES emulation in order to preserve broad compatibility. The author leaves evolution of the SES Compartment API to better resemble the native XS Compartment as a future exercise.

Upgrade Considerations

None yet.