Add a PHP Memory Readiness checker

@rivimey
You make a good point about not needing to worry about bootstrap memory needs for a usable site. However, there are still many other factors that can affect memory usage during in-place updates, as you mentioned.

I agree that memory profiling is a good approach to determine the factors that affect memory needs. By profiling the memory usage during different types of updates and configurations, we can identify the patterns and factors that contribute to higher memory usage.

Regarding the memory limit check, checking if the memory_limit value is greater than a certain threshold is a good start. As you mentioned, a value like 200MB could be a reasonable threshold, but it may need to be adjusted based on the specific needs of the site.

The second version you suggested, attempting to allocate blobs of memory until you run out, is not a good approach due to the potential problems it can cause on the host and in the PHP process. Instead, a more accurate approach would be to simulate the update process using a sample of the site's data and modules and measure the memory usage during the simulation. This would give us a more accurate estimate of the peak memory usage during an actual update.

Overall, a combination of approaches, including memory profiling and simulation, can help us develop a more accurate and effective PHP memory readiness check for in-place updates.

The probability of failure used to be high in Composer 1.

In Composer 2, it's very low.

Furthermore, it's impossible to know how much memory Composer will need. It depends on the complexity of the project.

That's why I believe 📌 Add functional test that proves there is reasonable UX whenever a stage event subscriber has an exception Fixed is sufficient to handle this.