feat(xsnap)!: Update Moddable SDK and xsnap-native

[mhofman]

closes: #6759
supersedes: #6011 #6768

Description

Updates our old fork of the Moddable SDK to the official 3.7.0 version

Updates xsnap-native with the following changes (details at agoric-labs/xsnap-pub#34):

• handle profiler and instrumentation changes (disabled)
• updated promise queue behavior

Security Considerations

This update contains a lot of bug fixes in XS found by fuzzing tools. This should be a strict improvement.

Scaling Considerations

None

Documentation Considerations

None

Testing Considerations

Followed the following process (now described in #6929)

• Created a "chain transcript" from mainnet using a follower based on the pismoC version of XS (minus agoric-sdk version bump), equivalent to mhofman/pismo-with-replay-tools-improvements-updated-xs~1
• Replayed "chain transcript" using updated version of xsnap-worker (slightly different revision actually tested, but no effective changes to xsnap-worker), equivalent to branch mhofman/pismo-with-replay-tools-improvements-updated-xs
• Extracted vat transcripts
• Replayed vat transcripts by forcing a reload into a new worker after each snapshot being taken, and comparing the execution and snapshot hashes with workers that didn't reload.
• Observed no anachrophobia nor any snapshot hash differences indicating that no reload based divergences were experience on the mainnet derived data set

(PR #6931 for chain transcript replay tool against master)

[mhofman]

Apparently something broke, and I'm surprised the testing I didn't uncover these issues.

[warner]

I skimmed the xsnap changes and they look great. I couldn't look at the xs changes.. as usual we rely upon upstream's diligence and your thorough testing.

Not sure what's going on with the test (slogSender something?), but assuming it's something trivial, I think the PR is good to go once it works again.

(hm, I did notice some more file descriptors referenced in the xsnap code.. but I think that only happens if you ask for instrumentation/debugging to be turned on. There's a remote chance that the extra FDs used for the slogsender pipe are getting inherited by the xsnap child process and colliding with something it wants to use for debugging. That would qualify as a non-trivial problem :)

[mhofman]

Not sure what's going on with the test (slogSender something?), but assuming it's something trivial, I think the PR is good to go once it works again.

(hm, I did notice some more file descriptors referenced in the xsnap code.. but I think that only happens if you ask for instrumentation/debugging to be turned on. There's a remote chance that the extra FDs used for the slogsender pipe are getting inherited by the xsnap child process and colliding with something it wants to use for debugging. That would qualify as a non-trivial problem :)

Oh that's an excellent idea. When I ran my tests I hadn't had time to fully understand the instrumentation changes, so I had ommitted that commit entirely. As described at agoric-labs/xsnap-pub#34, I didn't feel fully confident in them so I disabled them using the build option, thinking the new select would result in a no-op because we're not using these FDs, but maybe that isn't the case. I'll do more testing.

[mhofman]

I figured it out: faulty disablement of the new intrument logic, and that code hangs if the fd doesn't exist. More info at agoric-labs/xsnap-pub#34 (comment)

[mhofman]

@warner, all checks are green, PTAL

[warner]

recent changes to xsnap/ look good, I think we're go