feat: delay scheduled restarts while players are online

[mattibat]

Problem

• Scheduled restarts always fire at the exact time, even with players online

Change

• New option Delay Restart Until Empty (off by default)
• When enabled, a scheduled restart waits until the server is empty
• Forced after Max Restart Delay (15m / 30m / 1h / 2h, default 30m)
• Sidebar shows the delayed state, and the delayed restart can be skipped

[yorick2002]

This is stupid

[mattibat]

This is stupid

Thats actually a good feature in my opinion, i used it myself on my servers. if yall dont like it, its disabled by default, so?

[tabarra]

Thanks for the PR!
In theory I think a player-count-aware restarter is a good idea and worth adding since restarting the server when you are at the long tail of players is a sure way to kill the gameplay for the upcoming hours, but I am not sure about implementation details. Some things that come to mind:

1. How do we conciliate a fast changing variable (player count) with a steady and trusty advanced restart warning? From what I read on your code, it looks like there is no events being sent to the server about these delays.
2. The user-facinbg state was already too complicated and now it's even more, I think the right mechanism for this delay would be a skip + temp schedule X minutes ahead, of which can be skipped + rescheduled again if needed.
3. We should not await the last minute to make a decision, if by T-5mins we still have more players than the limit, then we should already make the decision of delaying it or not.
4. This decision should also be a relevant extension, not single more minute, but more like 15, 30 mins or even 1 hour. But if the player count goes to literally zero I think it makes sense to shortcut that.
5. About the threshold, a "wait until empty" would be fine by most servers but terrible for every big server that has players all day round, because that would result in the restart warnings being "wrong" literally every single day.
6. Softer or dynamic approaches would likely be better, maybe one of:
   1. Delay only if player count is above average for the current hour compared to previous days
   2. Delay until player count is under some percentile/quantile of the last 24h (maybe like 20% or so)
7. It's definitely time for me to convert the scheduler to use the MinuteScheduler.ts instead of this low precision crap I wrote years ago.

I am not sure what these mean for this PR, but it would like to leave it open to collect some feedback on it.

[mattibat]

Thanks for the detailed feedback, that all makes sense.

You're right about the warnings.
The skip + temp schedule approach is much cleaner, since it reuses the existing
warning flow and drops the extra delayed state entirely. Deciding at T-5 with a
15/30/60 min extension and a shortcut at zero players sounds right to me.
Agreed that "until empty" doesn't work for big servers. A percentile of the last
24h seems the most predictable of the two options to me, but happy to go with
whatever you prefer.
In addition, a smart restart mode could be a feature on its own: take the
player counts from the last 1-7 days, predict the time with the lowest activity,
and schedule the restart for that time. Since the time would be known ahead,
the regular warnings would still go out reliably.
Since you're planning to move the scheduler to MinuteScheduler, I'm happy to
rework this on top of that once it lands, or leave it open for feedback as you
said. Whatever works best for you.