Replace the current Timer implementation to only use loop.time() (not datetime)

[leandro-lucarella-frequenz]

The current timer implementation is like this:

        now = datetime.now(timezone.utc)
        diff = self._next_msg_time - now
        while diff.total_seconds() > 0:
            await asyncio.sleep(diff.total_seconds())
            now = datetime.now(timezone.utc)
            diff = self._next_msg_time - now
        self._now = now


        self._next_msg_time = self._now + self._interval

This might have issues as it works with absolute wall time, so if there are changes in the wall clock the timer could fire in a time quite different to the requested interval.

We could relay the timer handling to asyncio.loop.call_later() which uses the monothonic loop.time().

For a periodic timer (#78) we could see if asyncio.loop.call_at() is a better alternative, but we need to be careful and see what happens if the wall clock jumps around (daylight saving time, leap second, etc.). (BTW, call_at also uses the monotonic clock as the argument should be a asyncio.get_running_loop().time(), not a datetime).

We should use asyncio.get_running_loop().time() instead of datetime.now(). Also, I don't think we need to loop, sleep() should be guaranteed to sleep for at least what it receives.

I'm not sure why the current approach was used, probably something to discuss with @sahas-subramanian-frequenz

[leandro-lucarella-frequenz]

Updated to keep using sleep() as it is the high level interface, (call_later() and call_at() are low level as they require callbacks). What we really need to avoid to have the timer use the monotonic clock is using datetime() to check how much time passed, we should use asyncio.get_running_loop().time() instead.

[leandro-lucarella-frequenz]

The new PeriodicTimer is written like suggested here:

• Make the timer generic and support periodic timers #79