feat: initial xsnap vat metering for compute, stack, allocation

[dckc]

fixes #2972

note #2980, #2979 are postponed.

[dckc]

I'm switching to draft until more tests pass. I'd like to squash a couple fixups...

[kriskowal]

Just one important suggestion, and looks good.

[dckc]

@warner I'm standing by for your review. Let me know if you'd rather I just went ahead based on @kriskowal 's.

[warner]

Everything looks good to me (minor suggestions made) except the question of the api.js import. If we can find an answer quickly, I'd like to incorporate it. If we can't, I'm ok with landing it as-is and fixing it properly next week.

[warner]

@dckc when you looked at the slog output, you saw the new allocation meter value appear in the delivery-results event, right? That means it's being plumbed all the way back, great. If not, we might need to fix something in supervisor-helper.js to pass it through.

[dckc]

@dckc when you looked at the slog output, you saw the new allocation meter value appear in the delivery-results event, right?

Yes; this is documented in the .dr part of the (perhaps somewhat cryptic) comment:

	// SLOGFILE=out.slog agoric start local-chain
	// jq -s '.|.[]|.dr[2].allocate' < out.slog|grep -v null|sort -u | sort -nr
	int MB = 1024 * 1024;
	int measured_max = 30 * MB;
	the->allocationLimit = 10 * measured_max;

[warner]

@dckc thanks for landing this. A brief nit: the commits in this branch aren't really independent, so I think it'd have been better to land them with a merge commit, rather than a fast-forward (e.g. see the previously-landed PR, #2982, which used 7be8d71 to merge 6 related commits). My goal is for the left-side path of a git branch diagram (the first parent of each commit) to always pass all tests, and a merge commit is how we can retain this property in the face of groups of commits that need to be landed all-or-nothing. Thanks!

[dckc]

Oh! I forgot about that distinction between a merge and a rebase. Thanks for clarifying.