migrate-from-base tests have gotten long in the tooth

from the horse's mouth: https://github.com/oxidecomputer/propolis/blob/96e772ab174bb38897c42aef6951fbe7b3e40642/.github/buildomat/jobs/phd-run-migrate-from-base.sh#L16-L25

now, a test migrating from mainline propolis-server to the version under test (and back!) is useful, so unlike the comment remarks, I haven't been particularly interested in removing the test. but a few things have changed that make this test less useful than we'd want here..

first, we've stabilized HTTP API versioning across services. now, adding a new HTTP API version to Propolis implies this test will fail, until the new HTTP API version is landed, which would get master and the build under test speaking the same version again. other tests that the version under test can migrate to and from itself probably still pass in those cases! but by adding a new HTTP API version N, migrating to a propolis that only knows version HTTP API N-1 means the old propolis-server just returns an error and the test fails.

perhaps we should have migrate-from-base skip when we're bumping the HTTP API, and as a matter of policy(?) require that HTTP API plumbing not be changed alongside changes to propolis-standalone/propolis-server themselves? "policy" is a pretty subjective and unsatisfactory bar!

second, a VM can have a more storied life, especially once we start actually doing live migration. a VM first incarnated in a Propolis using the V1 API may live-migrate to a Propolis with a V2 InstanceSpec, which may live-migrate to a Propolis with a V3 instance spec. testing that this can migrate to the version under test is important, and is currently untested.

migrating forward along this path should always work, regardless of API version that the propolis-server under test would use in talking to other Propolises.

Start with .github/buildomat/jobs/phd-run-migrate-from-base.sh, especially lines 16-25, and inspect the existing migrate-from-base test and related migration tests. Compare coverage for API-version bumps and multi-version VM migration. Done means the test remains useful while covering forward migration across API versions without failing solely because the HTTP API version changed.