Replace sleep_until with sleep_for to prevent clock from getting stuck with system time adjustment

[RobertMueller2]

I think this addresses #1226 and potentially #1497.

• observe the change in general
• test some system time jumps
• test the simple clock module

On FreeBSD, the change does not have any effect, but doesn't make it worse, either.

[alebastr]

Funny (and annoying) fact: until late 2019 (gcc-mirror/gcc@ad4d1d2 - gcc 10.1, llvm/llvm-project@85e26f5 - llvm libc++ 10.0) std::condition_variable::wait_for() in both popular STL implementations was using CLOCK_REALTIME and thus had the same issue as wait_until().
The commits above addressed the issue for Linux with glibc >= 2.30, but FreeBSD, Alpine (musl) and anything else not using glibc are out of luck.

Useless trivia aside, the change improves the situation on most of the Linux distros which is already very good. Thanks!

[RobertMueller2]

I have tested this now and it's OK, I could not get the clock stuck on my Debian system when adjusting time. The interval alignment looked OK to me, too. With a meson file trick, I've also built and tested the simpleclock.

I've also built on alpine-latest utilizing the Dockerfile in the repo. Had to install some fonts on top -- but to my surprise it actually got along with adjusting the time just fine.

On FreeBSD, as expected, this doesn't help at all. But this has to affect the other modules using thread::sleep_for as well. I don't know if it's possible or feasible to add a lower level workaround, I don't think I could or at least not in finite amount of time. ;) The problem is not too intuitive, but it only happens under very specific circumstances where I'd say SIGUSR2 has to be good enough.

[Alexays]

Thx!