feat(swingset): add controller.terminateVat(vatID, reason)

[warner]

This new API allows the host application to terminate any vat for which is knows the VatID (which must be gleaned manually from logs or the database). This might be useful if the normal vat code is unable or unwilling to terminate the vat, or if you need to trigger termination at some specific point in time.

closes #8687

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	693b367
Status:	✅  Deploy successful!
Preview URL:	https://43cb910d.agoric-sdk.pages.dev
Branch Preview URL:	https://warner-8687-controller-termi.agoric-sdk.pages.dev

View logs

[warner]

Security Considerations

The new API is powerful, and uses a trivially-forgeable vatID string, but is only available to the host application.

Scaling Considerations

As noted in the docstring, unless a runPolicy is used to rate-limit cleanups, all vat state will be terminated during the first controller.run() call after this new controller.terminateVat() is invoked. That state might be large, and deleting it all at once could be a problem. This PR is targeted to land on top of the #8928 rate-limited cleanup branch, to enable host applications to avoid this problem.

Documentation Considerations

Nothing here should be visible to userspace developers. The primary audience of this new feature is a specialized cosmic-swingset upgrade handler, which can call it during some future chain upgrade, to initiate deletion of the then-unused large price-feed vats, after they have been replaced by others. It's entirely possible that userspace will have a way to delete these vats by then, and we won't need the host-app to do it.

Testing Considerations

If/when we write that future upgrade handler to invoke this, we will need some kind of main-fork test to make sure it can initiate termination correctly. That will be part of the PR which modifies cosmic-swingset.

Upgrade Considerations

none

[mhofman]

This all seems reasonable, even though I'm not sure in which (non-test) circumstance we'd want to use this mechanism as I'd expect us to use bootstrap powers instead to terminate a vat during some core proposal.

[warner]

This all seems reasonable, even though I'm not sure in which (non-test) circumstance we'd want to use this mechanism as I'd expect us to use bootstrap powers instead to terminate a vat during some core proposal.

Yeah, it wasn't 100% clear to me that the mainnet bootstrap vat has access to the necessary adminNode facets.. for contract vats, they might be held inside Zoe and not exposed to bootstrap. So this is a just-in-case. But it would also useful for non-critical static vats. In conjunction with a clear-criticalVat feature that we should probably add, it'd be the only way to terminate the bootstrap vat (unless vatPowers is available to core-eval proposals).

[gibson042]

Nice and compact!—although I do wish the testing was more self-contained; I'll have to see about DX improvements for bootstrap-relay.js.

[gibson042]

I don't know how strict we should be about assert patterns, but this is the convention AIUI:

Suggested change

	assert(reasonCD.slots.length === 0, 'no slots allowed in reason');
	reasonCD.slots.length === 0 || Fail`no slots allowed in reason`;