Disable server thread automatic cyclic garbage collection, and let PM MemoryManager exclusively decide when to run GC

[dktapps]

Description

As of PHP 7.3, GC roots are always recorded. Before 7.3, only the first 10k roots were recorded while automatic GC was turned off, and the remainder would be ignored, leading to potential memory leaks.

Since the GC can be triggered automatically seemingly at random when the GC root buffer reaches a certain size, seemingly random lag spikes can occur in code that wouldn't otherwise be slow, causing weird outputs on timings reports.

Instead, I think it makes sense to disable automatic GC and have the server decide when to do it. This would have the following benefits:

• No random lag spikes due to GC kicking in when an object happens to get destructed. This will improve performance in hot code paths.
• Time spent by the garbage collector can be properly accounted for in timings, since MemoryManager periodic GC is covered by timings already. Currrently, timings can only account for manual GC runs, and automatic ones triggered by Zend are hidden in other timings.

Downsides:

• It's possible that hot loops in plugin code may generate enough cyclic references to cause an OOM before MemoryManager can clean up. However, if this does happen, it should be obvious to plugin devs that their code has a problem.

[dktapps]

My initial attempts at this involved using gc_disable(), and then temporarily enabling it during MemoryManager::tick(), and then attempting to trigger GC by destroying an object to allow PHP's regular GC heuristics to decide whether to try running GC or not. However, this was unsuccessful, since I wasn't able to find a way to trigger a GC run without creating a cycle, which adds objects to the GC root buffer and ends up triggering more frequent GC runs.

[dktapps]

This may become viable with PHP 8.3 thanks to new information added to gc_status()