RFC: Support Read-Only opcache.file_cache for use with Docker

Hello,

Following on from a chat with some very helpful contributors on GitHub
(https://github.com/php/php-src/issues/16484), I'd like to request
feedback on a change and potentially put it forward as an RFC please.

Change Description:

The opcache.file_cache folder must currently be writable, but I
propose a read-only mode (potentially enabled via
opcache.file_cache_read_only=1) that allows the folder to be used
for loading files when it isn't writable.

opcache.file_cache_read_only=1 will fail unless
opcache.validate_timestamps=0 and opcache.revalidate_freq=0,
indicating the code is intended to be read-only.

An example PR to achieve this is here:
https://github.com/php/php-src/pull/16551 (I'd love some feedback
please!).

Why?:

When building containers (i.e. Docker) that contain both the PHP
runtime and application code (that isn’t going to change once built
into the container), a lot of CPU cycles are wasted re-warming the
opcache every time an instance of the container starts, even though
the code will always remain the same.

In a large distributed container based platform like Lambda, App
Runner, App Engine or Cloud Run, there are significant performance
gains & cost savings to be realised by being able to pre-warm the JIT
at container build time (i.e. in the CI/CD pipeline), then load it
from disk at container startup.

It is fairly common on these large container platforms for the entire
file-system to be read-only (e.g. Kubernetes readOnlyRootFilesystem)
as a security hardening measure, which makes using the existing
opcache.file_cache impossible.

Usage:

The intended usage for this change is to build the opcache via the CLI
in the CI/CD workflow, with something like this:

@php -dopcache.enable_cli=true -dopcache.file_cache=$(pwd)/opcache -dopcache.file_cache_only=true prewarm.php

<?php

/**
 * Composer autoloader...
 */

$filesToLoad = require __DIR__ . '/vendor/composer/autoload_files.php';

// Prevent composer autoloading files...
foreach ($filesToLoad as $fileIdentifier => $file) {
    $GLOBALS['__composer_autoload_files'][$fileIdentifier] = true;
}

require __DIR__ . '/vendor/autoload.php';

$finder = (new Symfony\Component\Finder\Finder())
    ->files()
    ->name('/\.php$/')
    ->ignoreDotFiles(false)
    ->ignoreVCSIgnored(false)
    ->exclude([
        'vendor/composer',
    ])
    ->notPath([
        'fuel/core/bootstrap.php',
        'fuel/core/vendor/htmlawed/htmlawed.php',
    ])
    ->in(__DIR__);

foreach($finder as $file) {
    $filepath = $file->getRealPath();
    echo "Compiling file " . $file->getRelativePathname() . " ... " .
        (
            opcache_is_script_cached($filepath) ?
                'EXISTS' : (
                    opcache_compile_file($filepath) ? 'OK' : 'FAIL'
                )
        ) .
        "\n";
}

Then including the opcache folder, along with the application code,
and the following values in php.ini inside the Docker container
build:

; Tune opcache
opcache.revalidate_freq=0
...other values...
## this below should be true on production
opcache.enable_file_override=true
## this below should be false on production
opcache.validate_timestamps=false

; Enable pre-warmed opcache
opcache.file_cache=/workspace/opcache
opcache.file_cache_read_only=true
opcache.file_cache_consistency_checks=false

Considerations:

Part of the opcache file path when stored on disk is the
zend_system_id, which from my testing, only stays the same on the
exact same build of PHP (and as a result this means if your service is
restarting to install a PHP update, the opcache files are no longer
valid anyway, but not necessarily a problem with Docker containers
that stay static until updated as a whole).

Benchmarks:

First request without opcache warm'd:

$ curl -w "@curl-format.txt" -o /dev/null -s http://localhost:32768/_ah/warmup
     time_namelookup:  0.000032s
        time_connect:  0.000160s
     time_appconnect:  0.000000s
    time_pretransfer:  0.000193s
       time_redirect:  0.000000s
  time_starttransfer:  0.221376s
                     ----------
          time_total:  0.221478s

First request with opcache pre-warm'd:

$ curl -w "@curl-format.txt" -o /dev/null -s http://localhost:32768/_ah/warmup
     time_namelookup:  0.000029s
        time_connect:  0.000164s
     time_appconnect:  0.000000s
    time_pretransfer:  0.000198s
       time_redirect:  0.000000s
  time_starttransfer:  0.053059s
                     ----------
          time_total:  0.053171s

The CPU on the machine I'm testing from is a lot more powerful than
the CPU allocation for containers in production (it's lots of small
instances that scale horizontally), so I'm expecting the improvement
to be even more dramatic there.

Struggling to benchmark that properly though, as prod/pre-prod for
serverless all has a read-only root FS.

** What does everyone think? Feedback welcome please. **