feat: max requests via caddyfile

[AlliBalliBaba]

Not yet sure if this is worth merging since it is currently handled on the PHP side, but it has been requested before.

worker {
  file worker.php
  max_requests: 1000 #after 1000 requests frankenphp_handle_request() will return 'false'

[henderkes]

While I'd like to see this moved to the caddy, rather than the php side, I don't think it's a good idea to split it into two ways.

If we want to keep it in php land, we can achieve the same with:

worker {
    ...
    env FRANKENPHP_MAX_REQUESTS 1000
}

[AlliBalliBaba]

@henderkes how would you fully move it to the Caddy side?

[withinboredom]

I think I like this idea for several reasons, after creating a custom worker script:

1. this makes worker restarts simple and thus worker scripts simpler.
2. some worker script authors might use FRANKENPHP_MAX_REQUESTS, some might use FOO_RESTARTS or somesuch, which just confuses things.
3. if you do need to schedule something to run on restart/shutdown, you can just use a shutdown function in the worker script.

[dunglas]

On my side, I prefer delegating everything that can be done in PHP to the userland script.

This allows keeping FrankenPHP's code base simple, and gives maximum flexibility to frameworks integration FrankenPHP, which can use various metrics to restart the script (number of handled requests, memory, time...).

[henderkes]

At this point, not at all, because of backwards compatibiใity, but if it weren't for that, then because of these two reasons Rob listed:

• this makes worker restarts simple and thus worker scripts simpler.
• some worker script authors might use FRANKENPHP_MAX_REQUESTS, some might use FOO_RESTARTS or somesuch, which just confuses things.

And also because:

• in my opinion, applications shouldn't tightly couple their logic to a specific webserver - the runtime component aims to somewhat solve this, but I would prefer a native solution once more webservers implement worker mode
• performance, even if minor

Keeping it in php land also has advantages, but I feel like it's a webserver thing more than an application thing and that unification is preferable in the long term.