fix(xsnap)!: upgrade to latest XS

[warner]

• fix a major memory leak: 64 bytes per Map delete(), 32 per Set delete()
  • should: closes increasing end-of-crank time consumed in testnet4.5 vattp trace, promises not getting GCed? XS bug? #3839
• unfortunately Map/Set deletion is now O(N) not O(1)
• possibly fix Bad address - cannot read snapshot for v10:zoe - KERNEL PANIC #3877 "cannot read (corrupted?) snapshot"

Note that this breaks snapshot compatibility, and probably metering
compatibility.

closes #3889

@dckc a few questions:

• The swingset unit test needed to be changed because the snapshot format has changed. I added a "do two new runs get the same hash" test, which is nominally redundant with the "does this new run have the same hash as some previous run" test, to emphasize the property we expect, and so that when we change the format, we should expect to see the same-as-past test fail but the same-as-two-now test pass. Let me know if that makes sense.
• Similarly, the "is the compressed snapshot between 10% and 20% of the uncompressed size" test seemed brittle, I changed it to just <50%.
• I didn't change any metering tests, and nothing failed, which either means the XS changes didn't change metering behavior (which is entirely possible), or we don't have any tests which are picky enough about metering to tell (also possible). Do you think I should bump the metering version? And if so, is that an xsnap-pub change? And if that's true, any idea how we should coordinate making changes in the xsnap-pub repo in reaction to changes in the xs repo?
• I haven't tried to update xsnap-pub yet, I'll look at that separately. Tests passed, so I'm guessing that the XS changes didn't really require e.g. additions to the callback table that xsnap has to manage (one big/obvious reason for snapshot incompatibility). Does that seem likely?

[dckc]

• The swingset unit test needed to be changed because the snapshot format has changed.

I hadn't thought of that as a breaking change. Perhaps change the comment above the 'XS + SES snapshots are long-term deterministic' test to emphasize that?

... I added a "do two new runs get the same hash" test

sure, that's fine.

• Similarly, the "is the compressed snapshot between 10% and 20% of the uncompressed size" test seemed brittle, I changed it to just <50%.

yeah, I guess that's plenty to detect whether gzip is doing something or not; the exact ratio doesn't matter.

• I didn't change any metering tests, and nothing failed, which either means the XS changes didn't change metering behavior (which is entirely possible), or we don't have any tests which are picky enough about metering to tell (also possible). Do you think I should bump the metering version?

I'm a little surprised that neither the xsnap nor Zoe metering tests are failing. I would much prefer to see metering changes detected by tests. So I think not changing the metering version is OK.

But I also think it's OK to change it just to be conservative.

And if so, is that an xsnap-pub change?

No.

• ... I'm guessing that the XS changes didn't really require e.g. additions to the callback table ... Does that seem likely?

yes.

[dckc]

My habit is to put changes to submodule versions in their own commit.

I can't think of any reason that it's critical, though. Maybe it only matters when I'm rebasing stuff in my local tree.

[dckc]

"latest" isn't likely to be helpful down some weeks / months. I prefer to see something like "fix a major memory leak" in the commit headline.

[dckc]

Good stuff.

I have some suggestions, but nothing critical.

[warner]

Ok, updated the comments a bit, will land when CI finishes.