Introduce SchedulerBackend to fix VelocitySchedulerTest intermittent failure

[WouterGritter]

As the title says.

I was having intermittent failures because of these tests when building a Velocity fork on GitHub actions.

The culprit was already identified when the tests were first written:

// TODO: The timings here will be inaccurate on slow systems.

Note that DeterministicSchedulerBackend was written partially with the help of an LLM.

[Warriorrrr]

Do you have any link to a workflow run that failed because of this? Velocity uses github actions too and does not have this issue.

[electronicboy]

I think I managed to make it fail once when my system was on fire, having time based tests is often a bit of a nightmare, having testing envs work differently to real environments is also a bit of a wildcard too

[astei]

This seems fine to me - making the scheduler totally deterministic is the canonical solution to the problem, I just didn't have an incentive to deal with it.

FWIW, I would expect those tests to be most flaky on lower-end hardware and the last time I touched this, it was mostly to improve reliability but not all of it was made deterministic.

[WouterGritter]

For reference, a failed job before this merge: https://github.com/GemstoneGG/Velocity-CTD/actions/runs/21911993248/job/63268303163

But again, this build is for a velocity fork (though it didn't make any meaningful change to the scheduler).