IBX-11179: Resolve PHP 8.4 lazy proxy incompatibility

[wiewiurdp]

🎫 Issue	IBX-11179

Description:

This pull request removes the lazy loading mechanism from Doctrine EntityManager to ensure full PHP 8.4 compatibility. The issue arises from Symfony's lazy proxy factory limitation when handling nested lazy services, which is incompatible with PHP 8.4's strict lazy proxy requirements.

PHP 8.4 introduces stricter rules for lazy proxy handling. Symfony's lazy proxy factory cannot handle nested lazy services, resulting in the error: "Lazy proxy factory must return a non-lazy object". The current implementation of EntityManager relied on lazy loading, which violates this constraint.

The fix implements SiteAccessAwareEntityManager, a non-lazy decorator that wraps EntityManager and implements explicit lazy resolution via EntityManagerFactory.

(almost) green regressions : ibexa/commerce#1668
Results discussed with QA and these fails are known.

For QA:

Please do sanities with multirepository setup

Documentation:

[konradoboza]

We don't add new entries to PHPStan baseline in the new code, please resolve this one as well.

[wiewiurdp]

@konradoboza
The problem is that :

\Doctrine\ORM\EntityManagerInterface has:

/**
 * EntityManager interface
 *
 * @method Mapping\ClassMetadataFactory getMetadataFactory()
 * @method mixed wrapInTransaction(callable $func)
 * @method void refresh(object $object, ?int $lockMode = null)
 */
interface EntityManagerInterface extends ObjectManager

and in: \Doctrine\Persistence\ObjectManager

there is :

 /**
     * Gets the metadata factory used to gather the metadata of classes.
     *
     * @phpstan-return ClassMetadataFactory<ClassMetadata<object>>
     */
    public function getMetadataFactory();

Should I add phpstan line ignore to SiteAccessAwareEntityManager instead of adding it to phpstan-baseline ?

[konradoboza]

Should we also have decorates: here?
Regardless: doesn't that approach leave us with some technical debt we need to reassess later while upgrading dependencies late? I wonder how Doctrine themselves have dealt with providing support for PHP8.4. Have you checked that? First idea is the one we initially have - bumping the dependency version. However, maybe there is a specific PHP8.4-compatibility-related part we might be able to utilize for the time being.

POV ping @alongosz @Steveb-p.

[Steveb-p]

It should NOT decorate the primary Doctrine Entity Manager.

We only expect it to "overwrite" the default behavior specifically when we ask for ibexa.doctrine.orm.entity_manager service.

[Steveb-p]

As we discussed on daily meetup, I expect this $this->resolvedEntityManager to be reset when SiteAccess changes (Ibexa\Core\MVC\Symfony\MVCEvents::CONFIG_SCOPE_CHANGE or Ibexa\Core\MVC\Symfony\MVCEvents::CONFIG_SCOPE_RESTORE).

Additionally, up for debate within team, is whether we should use kernel.reset, since we have effectively a stateful service.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud