fix: workaround leak through promise resolvers

[mhofman]

The investigation into Agoric/agoric-sdk#5507 lead us into discovering a leak caused by promises, in particular when using Promise.race with a long pending promise. The root cause really seem that the promise resolve functions hold onto the promise strongly (instead of just an internal record representing the reactions registered on the promise), and through that, the result of said promise. Promise.race is implemented as adding the result's promise's resolver functions to each of the contenders reactions, causing the long pending promise to keep the raced result alive.

This PR re-implements Promise.race based on the solution in nodejs/node#17469 (comment). It also updates makePromiseKit to return resolvers that will sever their hold on the original resolvers (and thus the promise) once called. That latter approach, while simpler, is not sufficient for Promise.race as reactions would keep queueing on the long pending promise (engines are not sufficiently smart to realize a reaction is a native resolver that has become inert).

Finally it installs the new race implementation as a Promise.race vetted shim in @endo/init.

(I'm half considering re-writing promises in userland with proper support for short-circuiting, which would avoid most of these issues, but the few spec places creating primordial promises would damper that. A long term solution might be to rewrite the spec with proper short-circuiting, maybe as part of tc39/proposal-faster-promise-adoption)

[kriskowal]

We could alternately move this into ses as a taming of the existing Promise.race. It would only be a slight feature creep.

[michaelfig]

We could alternately move this into ses as a taming of the existing Promise.race. It would only be a slight feature creep.

Why not just as a separate "vetted shim" package, loaded by @endo/init?

[kriskowal]

We could alternately move this into ses as a taming of the existing Promise.race. It would only be a slight feature creep.

Why not just as a separate "vetted shim" package, loaded by @endo/init?

That’s even better.

[mhofman]

Updated to use a vetted shim approach, and reverted the explicit uses to rely on the shim.

Also updated the implementation to follow the spec more closely. It'd be nice to test against test262, but I don't believe we have the infra for that.

[erights]

Not done yet. Just giving you bits as they occur to minimize latency.

[erights]

I did not do a thorough review of memo-race.js . But nothing seemed wrong, and you already have @kriskowal 's approval. I'll defer to that. Please proceed.

[mhofman]

Added a blurb to NEWS.md and addressed @erights type feedback in 0377da0 then rebase the whole thing cleaning up the history: 0377da0..219e49d