Separate bootstrap event to signal server readiness

[Draykee]

Is your feature request related to a problem? Please describe.

During the development of features with extensive database preloading (e.g., checking roles, configurations, fetching tokens, etc.), issues arose with Kubernetes liveness probes. The bootstrap process took so long that liveness probes frequently timed out before the application was ready to receive requests.

The problem is that the current InitializerEvent that I used is triggered before the server is actually listening for requests. This causes time-consuming initialization logic that responds to this event to delay the availability of the server, leading to failed health checks and deployment issues in containerized environments.

Describe the solution you'd like

Introduce a new BootstrappedEvent that is triggered after app.listen() when the server is already capable of receiving HTTP requests. This allows:

• (still) Critical initialization logic to run before the BootstrappedEvent with the InitializerEvent (before the server accepts requests)
• Non-critical, async, time-consuming initialization logic to be deferred to the BootstrappedEvent (after the server is already available)
• Kubernetes liveness probes to succeed while background initialization is still running
• Better separation of concerns between "application initialized" (services/config available) and "application ready to serve traffic"

The new event would be published in the bootstrap() function right after the server starts listening:

Describe alternatives you've considered

• For k8s I can just increase the timeout durations for the liveness probes...
• I could use timers to load things delayed