Add run conditions for executing a system after a delay

[TimJentzsch]

Objective

I want to run a system once after a given delay.

• First, I tried using the on_timer run condition, but it uses a repeating timer, causing the system to run multiple times.
• Next, I tried combining the on_timer with the run_once run condition. However, this causes the timer to tick only once, so the system is never executed.

Solution

• Replace on_timer by on_time_interval and on_real_timer by on_real_time_interval to clarify the meaning (the old ones are deprecated to avoid a breaking change). (Reverted according to feedback)
• Add once_after_delay and once_after_real_delay to run the system exactly once after the delay, using TimerMode::Once.
• Add repeating_after_delay and repeating_after_real_delay to run the system indefinitely after the delay, using Timer::finished instead of Timer::just_finished.

---

Changelog

Added

• once_after_delay and once_after_real_delay run conditions to run the system exactly once after the delay, using TimerMode::Once.
• repeating_after_delay and repeating_after_real_delay run conditions to run the system indefinitely after the delay, using Timer::finished instead of Timer::just_finished.

[alice-i-cecile]

I really like this change (it's flexible and intuitively matches the name), but I think it's a usability regression in most cases.

Instead, I suggest we keep this change, but also:

1. Add a periodically (or whatever) run condition that works the same as the old on_timer condition.
2. Doc link between the two methods, explaining why you might want the more verbose form.
3. Replicate this for the on_real_timer variant.

[TimJentzsch]

I really like this change (it's flexible and intuitively matches the name), but I think it's a usability regression in most cases.

Instead, I suggest we keep this change, but also:

1. Add a `periodically` (or whatever) run condition that works the same as the old on_timer condition.

2. Doc link between the two methods, explaining why you might want the more verbose form.

3. Replicate this for the `on_real_timer` variant.

At this point I wonder if it's worth it to have the more verbose version, or if we have periodically and after_delay (or something similar) which both just take a Duration and handle the TimerMode internally.

Or maybe on_timer can stay as it is and after_delay is just an extra run condition, then the change isn't breaking anymore.

[alice-i-cecile]

Yeah, it might make sense just to have the two forms and don't ever expose the Timer form. At the same time, I think we should move away from on_timer as a name (use a deprecation if you do), just to avoid the same confusion you had. It's weird that it doesn't take a Timer argument!

[TimJentzsch]

Alright, I have deprecated the on_timer and on_real_timer names and added variants with TimerMode::Once.

[NthTensor]

Looks good to me. Nice docs.

[TimJentzsch]

As per https://discordapp.com/channels/691052431525675048/692572690833473578/1193685432442036235, I reverted the rename of the old run condition.