Refresh zend mm shadow key on fork

[arnaud-lb]

The memory manager is cleaned up after each request by calling shutdown_memory_manager(). At the same time, this prepares the manager for the next request, and the shadow key is refreshed.

Unfortunately, in forking SAPIs the first request of every child process inherits the memory manager of the parent process, including the shadow key. As a result, a leak of the shadow key during the first request of one process gives away the shadow key used during the first request of other processes. This does not defeat shadow pointers, but this makes the key refresh mechanism less useful.

Here I ensure that we refresh the shadow key after a fork. The memory manager is not empty at this point (we perform allocations after shutdown_memory_manager()), so we have to recompute any shadow pointers with the new key.

I'm targeting 8.4, but this is too risky and not critical enough for the last RC. I would like to merge this in 8.4.1.

Edit: now targeting 8.5.

ZTS: We assume that the forked process has only one thread, as anything else would be unsafe. If a SAPI forks a process running more than one thread, it is its responsibility to call refresh_memory_manager() in each PHP thread of the child process.

NB: I can't test litespeed.

UPGRADING.INTERNALS:

 * SAPIs must call `php_child_init()` after a fork. If the forked process runs multiple threads, `refresh_memory_manager()` must be called in each PHP thread of the child process.

[mvorisek]

Can these corruption cases be tested with a help of zend_test easily?

[arnaud-lb]

I tried, but this results in a fragile test

[nielsdos]

Makes sense, see my remarks

[nielsdos]

I can't test LiteSpeed either, but looking at all "fork" usages in PHP now, the CRIU checkpoint system in LiteSpeed may fork too:

https://github.com/php/php-src/blob/master/sapi/litespeed/lsapi_main.c#L1540 initializes CRIU support

php-src/sapi/litespeed/lscriu.c

Line 517 in b30ccf9

iPid = fork();

Anyway, this is likely not critical.