Feature request: Re-forking the preloader

[dannyfallon]

This is a rip off of the idea from Pitchfork. An active worker in our app that's serving traffic uses ~800MB of private memory:

* PID: 924584   Sessions: 1       Processed: 4220    Uptime: 12m 15s
    CPU: 65%     Memory  : 812M    Last used: 1s ago
  * PID: 924825   Sessions: 1       Processed: 3928    Uptime: 12m 13s
    CPU: 62%     Memory  : 782M    Last used: 1s ago
  * PID: 925038   Sessions: 1       Processed: 3952    Uptime: 12m 11s
    CPU: 63%     Memory  : 821M    Last used: 0s ago
  * PID: 925262   Sessions: 1       Processed: 4047    Uptime: 12m 10s
    CPU: 63%     Memory  : 809M    Last used: 2s ago

Sometimes we see even after a few hundred requests the memory usage grow:

  * PID: 935913   Sessions: 0       Processed: 337     Uptime: 11m 2s
    CPU: 8%      Memory  : 664M    Last used: 5s ago
  * PID: 936077   Sessions: 0       Processed: 223     Uptime: 11m 1s
    CPU: 5%      Memory  : 594M    Last used: 5s ago

And idle processes:

  * PID: 939530   Sessions: 0       Processed: 1       Uptime: 10m 16s
    CPU: 0%      Memory  : 196M    Last used: 2m 5s ago
  * PID: 939570   Sessions: 0       Processed: 0       Uptime: 10m 15s
    CPU: 0%      Memory  : 52M     Last used: 10m 15s ag

Pitchfork has a rather nice feature where a worker that reaches a threshold of requests processed becomes the pre-loader and the worker process pool is recycled to fork from this promoted worker to help with memory fragmentation and improve CoW/memory sharing. This is somewhat like the fork_worker that Puma added in Puma 5.

This probably needs more thought that just a GitHub issue and a description of the feature but since we're not planning on moving to containers yet Passenger's still our application server of choice.