feat: thread autoscaling

[Alliballibaba2]

I originally wanted to just create a PR that allows adding threads via the admin API, but after letting threads scale automatically, that PR kind of didn't make sense anymore by itself.

So here is what this PR does:

It adds 4 Caddy admin endpoints

POST     /frankenphp/workers/restart   # restarts workers (this can also be put into a smaller PR if necessary)
GET      /frankenphp/threads           # prints the current state of all threads (for debugging/caddytests)
PUT      /frankenphp/threads           # Adds a thread at runtime - accepts 'worker' and 'count' query parameters
DELETE   /frankenphp/threads           # Removes a thread at runtime - accepts 'worker' and 'count' query parameters

Additionally, the PR also introduces a new directive in the config: max_threads.

frankenphp {
    max_threads 200
    num_threads 40
}

If it's bigger than num_threads, worker and regular threads will attempt to autoscale after a request on a few different conditions:

• no thread was available to immediately handle the request
• the request was stalled for more than a few ms (15ms currently)
• no other scaling is happening at that time
• A CPU probe (50ms) successfully determines that PHP threads are consuming less than a predefined amount of CPU (80% currently)
• we have not reached max_threads yet

This is all still a WIP. I'm not yet sure if max_threads is the best way to configure autoscaling or if it's even necessary to have the PUT/DELETE endpoints. Maybe it would also make sense to determine max_threads based on available memory.
I'll conduct some benchmarks showing that this approach performs better than default settings in a lot of different scenarios (and makes people worry less about thread configuration).

In regards to recent issues, spawning and destroying threads would also make the server more stable if we're experiencing timeouts (not sure yet how to safely destroy running threads).

[AlliBalliBaba]

Alright I think this is ready to merge. Not sure why watcher installation is failing right now in asan and msan

[AlliBalliBaba]

@dunglas I'll merge this branch if that's ok.

It looks like the newest watcher version needs CLANG20 and CLANGXX20 (ubuntu-latest in the pipeline has CLANG18, but it's not a problem with GCC). I fixed the used watcher version to 0.13.2 for msan and asan for now.

Also, not sure what's up with the sudden false positives in the markdown linter.

[furan917]

@AlliBalliBaba Feel free to tell me I am wrong as I am just passing by and skim reading.

But isn't the linter fail a true fail with a hint of misconfig, ithe GHA is linting main and picking up the RU docs are missing their EOLs, right?

[AlliBalliBaba]

@furan917 Oh you are right, I didn't realize we had RU docs.

[dunglas]

Great work!! I made a bunch of comments, but this looks very close to be mergeable to me.

[AlliBalliBaba]

Alright, the debug state is now a struct and the endpoint is marked as 'experimental' and returns a JSON. Additionally, I added support for a nested php.ini configuration like this, since I think it's a very convenient feature

php_ini opcache.jit tracing

# or

php_ini {
	mysqlnd.collect_statistics Off
	opcache.jit tracing
}