fix(notifier)!: Stop retaining durable publish kit values in RAM

[gibson042]

Fixes #7298

Description

Refactor ephemeral data to retain a promise resolved to the current value only when that value is ephemeral, which is currently prohibited by the restriction of valueDurability to 'mandatory'.

Security Considerations

n/a

Scaling Considerations

This PR reduces RAM consumption by allowing durable promise kit resolution values to be paged out.

Documentation Considerations

This change is breaking only because the identity of promises and head objects is no longer preserved, but I don't believe we ever promised such preservation and it isn't observable across vat boundaries anyway.

Testing Considerations

I still want a test that verifies lack of retention, and am open to ideas regarding the best pattern for that.

[FUDCo]

This all looks quite sensible to me, but it's far enough outside my wheelhouse that I'm not comfortable giving it a thumbs up (or down) just on my own. So consider this a kinda-sorta approval conditional on someone whose promise-fu is greater than mine giving it their blessing.

[michaelfig]

LGTM. IIUC, avoiding keeping currentP around where possible and reconstituting it when necessary is what makes this change use less memory.

I'll defer to your preference on whether if or switch is better for dispatching state.status.

[michaelfig]

Maybe use switch (status) here?

[gibson042]

Considered, but rejected because I want provideCurrentP and provideDurablePublishKitEphemeralData to remain compact.

[michaelfig]

Again?

[mhofman]

I admittedly do not grok enough the publisher/subscribers to consider my review authoritative, but I have concerns about the handling of non-durable finish values and fail reasons. Arguably this was a problem before, but I have a hard time figuring out the state in which it leaves the ephemeral data.

On the memory usage, an empirical test seem to indicate we no longer hold virtual objects through the ephemeral data, so that's good! Of course we do still have a bunch of heap promise per publisher, but not much to do about this until we implement pseudo-promises.

[mhofman]

Why import the resolve definition? It's pretty standard:

Suggested change

	* @property {import('@endo/promise-kit').PromiseKit<*>['resolve'] | undefined} tailR The next-result resolver
	* @property {((value: *) => void) | undefined} tailR The next-result resolver

[gibson042]

Done.

[mhofman]

So I actually found one more leak, at least in v8. Apparently the Errors structured stack keeps references to each call site, including in this case the context object of the finish call. That object is the {state, facets} context of the notifier exo kit. While this is most likely not a problem in XS, and likely applies to other Exo class based patterns, I figured it'd be easy enough to fix in this case since I don't believe there is much value in capturing the stack of when the publisher was finished.

Suggested change

	const makeTooFarRejection = () =>
	makeQuietRejection(new Error('Cannot read past end of iteration.'));
	const tooFarRejection = harden(
	makeQuietRejection(new Error('Cannot read past end of iteration.')),
	);

[gibson042]

Fixed.

[mhofman]

So the reason I suggested to harden was because the rejection would be shared instead of built for each publisher when reaching a terminal state.

[gibson042]

Yep, makes sense. And makeQuietRejection already hardens the returned promise.