Add subnet support to the tmpnet fixture

[marun]

The tmpnet fixture supports e2e testing against temporary networks, but currently doesn't support deploying subnets. This precludes testing the xsvm example VM in avalanchego e2e and prevents the use of tmpnet by subnet-evm and hypersdk.

Tasks

• Use initial stakers as subnet validators

• Since subnet validators also need to validate the primary network, using initial stakers as subnet validators minimizes setup time and the number of nodes required to enable subnet testing.

  • A previous approach used ephemeral nodes to validate subnets required by a given test. Those nodes weren't safely ephemeral, though, since stopping enough of them (primary network validators all) could risk network quorum.

• Create subnets during suite setup

• The limiting factor of subnet deployment in testing is the duration to wait for validators to become active. The time cost of creating multiple subnets is effectively the same as a creating a single subnet.

  • Deploying n subnets at once during suite setup takes less time than deploying subnets individually in the context of dependent tests.
  • This calculus is likely to remain valid under continuous staking.

• Allow a test to retrieve the details of its subnet(s) from the tmpnet fixture

  • Since subnet IDs are the result of network transactions and can only be known at runtime, subnets created as part of suite setup will need to be associated with a hard-coded identifier to allow tests to discover the details of a subnet that will only be known at runtime (e.g. subnet id, node IDs of validating nodes, owning key, etc).
  • Subnet details will need to be serialized to disk (i.e. as part of the network) to support retrieval across test runs.

• Support creating custom chains at-most-once

  • Every custom chain for a given subnet starts a VM process on all nodes validating the subnet. If a test creates a custom chain every time it is run, and the test is run repeatedly against an existing temporary network, each run would create a new VM process and potentially lead to cumulative resource exhaustion. Requiring that custom chains be created at-most-once ensures that only a single VM process will be created no matter how many times a test is executed.

• Support optional network restart

  • When iterating on both node and VM behavior, it would ideally not be necessary to incur the cost of network start and subnet creation to validate a given change. This suggest enabling restart of an existing network with updated binaries to allow reuse of network state (e.g. via a tmpnetctl command or --restart-existing-network flag to the test binary).

• Allow skipping subnet-requiring tests and the associated setup costs Skipping for now

  • Adding support for subnet creation as part of a common suite setup adds overhead to the development of tests that don't require subnets. Ensuring that subnet-requiring tests and their setup can be optionally skipped minimizes the setup cost required for non-subnet testing.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.