[!!!][FEATURE] Share test instances between identically configured test cases

[bmack]

Functional test instances are identified by sha1(static::class), so every test case class
provisions its own instance: its own directory tree, its own compiled dependency injection
container and its own database schema. Across the TYPO3 core corpus that is 764 instances,
while only 207 distinct instance configurations exist.

This series keys instances on what actually shapes them — the extensions to load, the paths to
link and provide, the configuration overrides, the folders to create, whether the database is
initialised — so test cases configured identically share one instance. It is provisioned once,
its container is compiled once, its schema is created once.

Blast radius

Probably the first thing you want to know, since this carries [!!!].

getInstanceIdentifier() and getInstancePath() become non-static. They cannot stay static: a
test case may assign the configuration properties in its own setUp() before calling
parent::setUp(), and a static method cannot see those assignments.

• Both are @internal, and getInstancePath()'s docblock already stated "This may break
  anytime."
• Neither typo3/cms nor this repository calls them statically any more — core's call sites
  were converted upstream in 17e81da849d.
• So the exposure is third-party test cases that call or override an @internal method. The
  first commit carries a migration note covering the three cases such a test case can be in.

Keeping them static via a holder that setUp() populates was considered and rejected — it would
put mutable static state back into FunctionalTestCase, which is the same class of coupling as
the pollution channels this commit fixes, and would leave a static signature whose result is only
meaningful between setUp() and tearDown(). The reasoning is in the commit message.

What to look at

Most of the diff is mechanism. The two decisions worth a reviewer's attention:

1. What goes into the fingerprint (getInstanceConfiguration()). Anything that shapes an
   instance's content but is missing from that list would let two genuinely different instances
   share an identifier — a silent wrong-green. The list is the load-bearing part.
2. Why the compiled DI container is deliberately not flushed at a test case boundary. The
   whole core cache group is dropped, but di is kept, because it depends only on the active
   package set — and keeping it is what makes sharing worth doing at all. If that reasoning is
   wrong, the speedup mostly evaporates.

Sharing an instance between test case classes exposes state that was previously private simply
because every test case owned an instance. Six such channels were found and are fixed here; the
commit message lists them individually.

Measurements

Layer 0 in isolation, full core corpus, measured 2026-07-31 against the then-current main:

DBMS	baseline	shared	delta
sqlite	1341.6 s	847.8 s	−36.8 %
Postgres	2109.8 s	1672.4 s	−20.7 %
MariaDB	identical outcome		~−20 %
MySQL			~−11 %

A more recent full-corpus run (2026-08-04, with the composer-mode work of the follow-up PR also
applied, but in classic mode where that work is largely inert) measured 1379.2 s → 945.9 s,
−31.4 % on sqlite.

Every comparison was made on assertion counts and failing test sets, not just totals. A suite
that stays green while quietly doing less work would otherwise look like a win.

Verification

Each commit was verified green individually against the full TYPO3 core functional corpus, with
the upstream testing framework run as a control arm in the same job. On the current base both
commits produce results identical to upstream: 12473 tests, 72962 assertions, 0 errors, the same
6 pre-existing failures.

Follow-up

A second PR provisions functional test instances in composer mode and builds on this one. The
TYPO3 core side of that work is prepared and waits on a release containing this PR. That is the
change this series exists for; the speedup here is what makes it affordable.