Add grabEntityManager(), resetDoctrineManager() and grabContainer()

[TavoNiievez]

Adds three accessors that dependent projects have been hand-writing for years. The counts below come from a survey of the test suites of 349 public repositories that depend on this module.

1. grabEntityManager() — 44 repositories wrote it themselves

_getEntityManager() is underscore-prefixed, so ModuleContainer excludes it from the Actor. Reaching the EntityManager meant a getModule('Symfony') reach-through, a grabService() call with a hardcoded id, or a custom Helper module. The corpus contains six different spellings of the same line, including four unrelated tutorial repos reading the public getModule('Doctrine2')->em property directly.

It delegates to _getEntityManager(), so it keeps resolving from the current container on every call and honours em_service. The service resolution moved into resolveEntityManager(), which also fixes a misleading message: the old one said "is not an instance of EntityManagerInterface" both when the service was missing entirely and when it was the wrong type.

2. resetDoctrineManager() — 41 repositories, the largest copy-paste cluster in the corpus

Ten repositories ship a byte-identical EntityManagerReset Helper module, with the same docblock — "Fix "The EntityManager is closed" after test failure" — and 31 more wire that class into a suite YAML.

This PR does not fix a live cross-test bug: 6cd2150 (#236) already did. Before that commit _getEntityManager() pinned the manager into permanentServices, so one failed flush left a closed EM that the connector re-injected into every subsequent test's container for the rest of the suite. Every repository in the corpus is pinned to ^3.1/^3.5, i.e. before that fix. What remains on main is a narrower window: a write after a failed flush within a single test, with no intervening request. So this gives those 41 projects a supported API instead of a copied Helper, and closes that window.

Semantics mirror doctrine-bundle's own private Registry::resetOrClearManager(): an open manager is cleared, a closed one is rebuilt. Recovery goes through Doctrine's registry, which swaps the lazy service in place so the application and module-doctrine see the reopened manager too. On Symfony 5.4 the entity manager service is not lazy (no LazyServiceDumper, no proxy-manager-bridge), and ManagerRegistry::resetService() throws there, so the client kernel is rebooted instead. doctrine.dbal.default_connection stays a permanent service in both paths, so the open test transaction survives.

_getEntityManager() applies the same registry recovery before handing the manager out. It is bounded: it only runs when isOpen() is already false, i.e. when the manager was going to throw anyway. Nothing is cached — the container remains the source of truth.

A module config key was considered and rejected: it would have to act in _before, where the container is milliseconds old and the manager is never closed yet.

3. grabContainer() — 41 repositories wrote it themselves

Same root cause: _getContainer() is underscore-prefixed. Most projects settled on $I->grabService('kernel')->getContainer(), which is subtly wrong — that is the application container, which cannot see private services, while _getContainer() returns test.service_container, which can. Tagged @part services alongside grabService().

Notes

• No composer.json change. Doctrine\Persistence\ManagerRegistry is already present via doctrine/orm (require-dev) and ::class never autoloads; every Doctrine touch is guarded by interface_exists() + instanceof + try/catch.
• The fixture app wires Doctrine by hand and had no registry to reset through, so it gains a minimal TestManagerRegistry, signature-compatible with doctrine/persistence 3.x and 4.x. The manager is rebuilt on the existing connection because the fixture database is in-memory, and the entity manager service is no longer shared so the container hands out the rebuilt one.

Verification

• composer phpstan (level max) and vendor/bin/phpunit tests green: 181 tests.
• Verified against Symfony 5.4 and 8.1, and against doctrine/persistence 3.4.5 and 4.2.0, by rewriting the constraint the way CI does.
• The full symfony-module-tests functional suite passes on 5.4 and 8.1 against this branch. Functional tests are proposed separately, one PR per version branch:
  • Add functional tests for grabEntityManager(), resetDoctrineManager() and grabContainer() symfony-module-tests#76 (5.4)
  • Add functional tests for grabEntityManager(), resetDoctrineManager() and grabContainer() symfony-module-tests#77 (6.4)
  • Add functional tests for grabEntityManager(), resetDoctrineManager() and grabContainer() symfony-module-tests#78 (7.4)
  • Add functional tests for grabEntityManager(), resetDoctrineManager() and grabContainer() symfony-module-tests#79 (8.1)
• Those four branches already pin the current dev-main (b336cca) in composer.lock, so no dependency bump is needed on them now; they go green once the lock points at a revision containing this PR.