Ensure that hook attributes are never parsed from a stale opcache

Problem/Motivation

A client site is seeing stale hook data in the key/value store after deployments. Tends to be in situations like moving an OOP hook to a different class or similar.

What follows is purely a theoretical idea of what the problem might be, I talked it through with @nicxvan in slack prior to opening this. Once there is a viable MR, will try to validate it against the client's deployment process. Also might have a brute force way to rule it in or out which hasn't been tried yet.

The theory is:

opcache.revalidate_freq is set to 2s (the default), or possibly more.

Code is deployed to a web head.

drush cr / drush deploy or similar is called immediately, clearing the container cache.

Just before the container is rebuilt, a web head gets a container cache miss and starts to rebuild the container. This happens before the 2s opcache revalidation frequency has expired so it operates on the old version of the code base.

The cli also starts rebuilding the container and clears the cache.

The web head writes back to the cache, based on the stale class attributes from opcache.

Everything after this will have the updated classes, but there is nothing to trigger a new container rebuild because the new container was already built and cached successfully - it's just the hook data that got overwritten.

Later drush crs outside a deployment will fix it - because that rebuilds the container and rebuilds the hook data on the entirely fresh code base.

Steps to reproduce

Proposed resolution

If the above is correct, it might be fixable with a call to opcache_invalidate() on a filecache miss - filecache already validates the mtime.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet