[php-src] PR #24320: Fix GH-24319: opcache hash entries can be seen before they are initialised

Pull Request: https://github.com/php/php-src/pull/24320 Author: iloveleon19 Fixes #24319. Prepared with an AI assistant; I reviewed the change and the test results. The text below is AI-generated (quoted, as asked in CONTRIBUTING.md). > zend_accel_hash_update() links a new entry into its bucket with > plain stores while holding the SHM lock, but > zend_accel_hash_find_ex() reads the hash without the lock. On weakly > ordered CPUs a reader can reach an entry whose > key/indirect/data > stores are not visible yet. Details and observations are in #24319. > > This uses the fence macros added for GH-23637 (873a997d): > - release fence before accel_hash->hash_table[index] = > entry, and before updating > data/indirect of an existing entry; > - acquire fence after loading a non-NULL bucket head in > zend_accel_hash_find_ex() and in > accelerator_get_scripts() > (opcache_get_status()). > > **Testing so far** > - The same change backported to 8.2.32 (on top of the GH-23637 fix): 0 crashes in 4368 reloads, > versus 9 crashes of this kind in 2607 reloads without it (FrankenPHP worker mode, aarch64, see the > issue for the caveats). > - This branch's version builds as a shared extension against PHP 8.4.26 ZTS with 873a997d > applied, with no new warnings in the touched files, and loads fine. > - An A/B reload run on PHP 8.4.23 + 873a997d, with and without this change (aarch64, FrankenPHP > 1.12.4), is in progress; I will post the numbers here. > > There is no phpt: this is a cross-thread ordering issue that we can only reproduce under load. > The direct→indirect conversion of an existing entry (two fields) is not made atomic by this > change; it is listed as an open point in the issue.