This PR was merged into the 6.4 branch.

Discussion
----------

[Runtime] fix compatibility with Symfony 7.4

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Issues        |
| License       | MIT

Since #60394 using `add()` is deprecated. This means that our tests can trigger deprecations on older branches when the high deps job is run. This usually is not an issue as we silence them with the `SYMFONY_DEPRECATIONS_HELPER` env var. However, phpt tests are run in a child process where the deprecation error handler of the PHPUnit bridge doesn't step in. Thus, for them deprecations are not silenced leading to failures.

We did something similar before in #60376.

Commits
-------

d39a7ac fix compatibility with Symfony 7.4

…e cache lock (mpdude)

This PR was squashed before being merged into the 6.4 branch.

Discussion
----------

[HttpCache] Hit the backend only once after waiting for the cache lock

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        |
| License       | MIT

When the `HttpCache` has to wait for a lock held by another, concurrent process, the `lock()` method wants to make sure we continue operation based on the most recent cache entry, possibly updated by the concurrent process.

So, after waiting for lock release, it calls `lookup()` to obtain this cache entry. This is, in fact, a reentrant call up into the current call stack.

Having `lookup()` multiple times on the call stack opens up a way to call the backend for validation multiple times. I have observed this in practice at least in combination with the `no-cache` cache-control header, causing surprising side effects™️ ✨.

Also without `no-cache` you can get strange-looking cache traces like `stale, valid, store, fresh`. Those occur only when concurrent locking is a issue.

I am not super happy with using an exception for a control flow issue like this. But, rolling back to `lookup` seems to be the most sensible decision for me, and using special return values to indicate this condition isn't really pretty either.

Commits
-------

df064b0 [HttpCache] Hit the backend only once after waiting for the cache lock

This PR was merged into the 6.4 branch.

Discussion
----------

Silence E_DEPRECATED and E_USER_DEPRECATED

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix #60528
| License       | MIT

This change works around php/php-src#17422

This shouldn't change much in practice because we report both not-silenced and silenced deprecations, except for the case when the native php error handler is triggered, which is what happens at this opcache stage, see php/php-src#18541 also.

Commits
-------

f21b2f4 Silence E_DEPRECATED and E_USER_DEPRECATED