This introduces a new 'neon_tenant: NeonTestTenant' fixture, which can
be used instead of a NeonEnv. All tests using 'neon_tenant' share the
same NeonEnv. NeonTestTenant provides many of the same members as
NeonEnv, like 'create_branch', 'endpoints' etc. But not the ones that
deal with storage, nor create_tenant.
I converted some existing tests to use the new fixture. More could be
converted, if we add more features to NeonTestTenant:
- Many tests grab the pageserver HTTP client and call GC / compact
functions on the pageserver. They are per-tenant operations, so they
could safely be done one a shared pageserver too.
- Some tests use failpoints to add delays or pauses to various operations
in the pageserver. If the failpoints were tenant- or timeline-scoped,
they could be used on a shared pageserver too.
- Some tests print intoduce errors in the pageserver logs. They set
allowlists for those error messages, because any unexpected errors
in the logs cause the test to fail. If the allowlist was tenant- or
timleine-scoped, we could allow those tests to share the env.
- Some tests use helper functions like check_restored_datadir_content or
fork_at_current_lsn, which take a NeonEnv as argument. They could use
NeonTestTenant instead (or become methods in NeonTestTenant).
- Some tests want to use extra tenant config for the initial tenant. We
could expand the neon_tenant fixture to allow that. (Perhaps introduce
NeonTestTenantBuilder which allows setting config before creating the
initial tenant)
- Some tests create multiple tenants. That could be allowed in a
shared env, as long as we track which tenants belong to the test.
See https://github.com/neondatabase/neon/issues/9193
b33ca57839