[FEATURE REQUEST] Boot trigger

[OO00O0O]

Problem Before Kernel starts and it can handle connections, a lot of work have to be done. For example:

• validating configuration
• warming up cashes
• checking connections
• building dependency tree

Solution 1 - any program, checks exit value. New config value server.boot. Same as services except it uses timeouts from worker pool and does not restart.

• 0 - start workers
• >=1 - error, stop everything, pass exit code and RR returns same code
• string - ?

  server:
  boot: "any_program.sh" 

Solution 2 - RR_MODE Use RR_MODE=boot and start one worker only. If it exists with 0, continue.

Solution 3 - new type packets Consider RR_MODE is moved to packet. Then RR starts one worker, sends BOOT packet, and if it responds with "everything is fine" continue booting other workers and accepting requests.

Solution 4 - ready packet I do not know if now RR sends packet when php worker is ready. But if not, it could send ready when first waitRequest call is made. I think time difference between workers starting is enough to avoid most race conditions. And custom boot logic could be avoided at all. First started worker could create file lock if more time is required.

[rustatian]

Thanks for the proposal, @OO00O0O, Solution 1 seems fine to me. The process can't return string exit code, so, it would be only 0 or >= 1, which is also fine. Generally, the proposal looks good to me. In the boot or I guess would be better on_init or init stage, RR executes the file/script provided by the path, and then if everything is fine (no timeouts, no non zero exit code) will continue to work. RR would not read the process output or communicate with the process, just fire and wait. Except for few things:

1. I can't read the pool timeouts (there are could be several pools, with different timeouts)
2. I guess, this section should look like the following:

   server:
    on_init:
        command: "any_program.sh/php"
        timeout: 10s
        other_possible_options.
   .... regular server's options......

   With this config, we would have the ability to easily extend on_init config option and provide the timeout. Regarding the #36 , we would have the ability to define per-plugin on_init scripts. I expect, that for the http and for example temporal workers, on_init routines might be different.