Move benchmarkerator and some test support code out of the boot package

[FUDCo]

This moves files around, creating two new packages: benchmark, containing the Benchmarkerator benchmarking framework, and test-support, containing support code that is used by both tests (mostly in boot) and Benchmarkerator. Code which uses the code that was moved has had the relevant import statements updated accordingly.

This completes work that was suggested by reviews to #8312 but which we chose to defer to its own separate PR for reasons of clarity and smoothness of transition to the new code state.

All of this is in support of #8327

[turadg]

the name test-support sounds much broader than that.

these also don't test on a chain, right? Just a swingset.

I request that you leave these in boot and export them under its tools. @agoric/benchmark can import them from there. I believe that's what you proposed and I supported in #8312 (comment)

If that complicates some other plans, let's chat

[FUDCo]

Yes, this would complicate other plans. There's little in those files that specifically pertains to the bootstrap tests, but they do contain the current best versions of some bits that are widely replicated throughout our suite of tests in a copy-paste-edit reuse with minor changes pattern. It's our hope to start cleaning that stuff up using common implementations of commonly used test boilerplate, which will want to draw on a common package for that stuff.

[FUDCo]

@turadg and I had a long chat about this. He feels quite strongly that the stuff about setting up a mock chain really belongs in the boot package since that's really what that package is all about. I'm not 100% sure I agree, but on the other hand I don't really have a very good counterargument either. We did agree that if the stuff is being used from the outside the package it does not belong buried layers down in the test directory. Instead, we're putting the support infra into the tools directory. The pieces of support code that I had flagged as being much more widely useful beyond just the bootstrap tests pertain to convenience sugaring for tests invoking the controller. This stuff has been broken out into a separate run-utils module and placed into SwingSet/tools, where it will be available to tests that are using SwingSet but not entraining the rest of the chain machinery. The test-support package is now gone. I will revise the PR title and descriptive commentary to match this resolution.

I think we still have some confusion to sort out with respect to the somewhat conflicted meaning of the tools directory, as we have used it to hold both "ancillary executables that are useful in a standalone mode" as well as "utility code that is outside the supported package APIs", sometimes even within the scope of a single package. However, this PR is not the place to resolve that.

[gibson042]

Setting aside benchmarkerator interface questions for now, I still have some suggestions.

[gibson042]

This assumption of a bootstrap-vat awaitVatObject method is giving off some bad vibes; is there a way to do it with just the controller? Untested idea:

Suggested change

	EV.get = presence =>
	new Proxy(harden({}), {
	get: (_t, pathElement, _rx) =>
	queueAndRun(() =>
	controller.queueToVatRoot('bootstrap', 'awaitVatObject', [
	presence,
	[pathElement],
	]),
	),
	});
	/**
	* Derives a value suitable for immediate interaction from a vat-originating value:
	* the fulfillment value of a fulfilled promise, or
	* the rejection value of a rejected promise, or
	* a non-promise value itself.
	* If `value` is an unsettled promise, a synchronous error will be thrown.
	*
	* @param {any} presence
	* @returns {{status: 'fulfilled' | 'rejected' | undefined, value: any}}
	*/
	const presenceSettlement = (presence, errPrefix = '') => {
	if (passStyleOf(presence) === 'promise') {
	const kpid = krefOf(presence);
	const status = controller.kpStatus(kpid);
	switch (status) {
	case 'fulfilled':
	// falls through
	case 'rejected':
	return { status, value: kunser(controller.kpResolution(kpid)) };
	case 'unresolved':
	throw Fail(`${b(errPrefix)}unsettled value for ${q(kpid)}`;
	default:
	throw Fail`${b(errPrefix)}unknown promise status ${q(kpid)} ${q(status)}`;
	}
	}
	return { status: undefined, value: presence };
	};
	EV.get = presence =>
	new Proxy(harden({}), {
	get: async (_t, key, _rx) => {
	await queueAndRun(() => {}, true);
	const errPrefix = '[EV.get] ';
	const { status, value: obj } = presenceSettlement(presence, errPrefix);
	if (status === 'rejected') {
	throw obj;
	} else if (passStyleOf(obj) === 'remotable') {
	throw Fail`${b(errPrefix)}Cannot read properties from remotable ${q(krefOf(obj))}`);
	}
	const { status: propStatus, value } = presenceSettlement(obj[key], errPrefix);
	if (propStatus === 'rejected') {
	throw value;
	}
	return value;
	},
	});

no more "test-support"

[warner]

Looks good.. my humblest apologies for taking so long. One question about the dependency changes in boot.. if those aren't necessary, I'd like to remove them (and of course if they are necessary, I just want to understand why).

Lemme know if I can help with rebasing this to bring it up-to-date and fix the bitrot-induced merge conflicts.

[warner]

Why do these need promotion to full dependencies, given that the benchmark (bench-vaults-performance) was moved out of this package? I kind of expect they'd be dependencies of the new packages/benchmark, but not this one.

[FUDCo]

Alas, a bunch of stuff that I wanted to move into packages/benchmark (and which were so relocated in the original version of this PR) are just moved to the tools directory of this package. There was some controversy about where various things belong, and the easiest immediate resolution was to leave them here. I would like to revisit this in a future PR, but I don't want to hold up landing this functionality for the resolution of this matter.