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]

You also need to handle pcntl_forkx, pcntl_rfork. Interestingly, we don't have vfork?
Anyway, I wonder if zend_max_execution_timer_init should be moved into php_child_init too.