systemclock: Fix various issues with clock id wakeups not actually waking up the waiting threads

commit ad0a3a4bf24f90f537b1bc9a49cd2a3ff6fc9ca0 (HEAD -> systemclock-waiting, gitlab-slomo/systemclock-waiting)
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Mon May 25 12:51:19 2020 +0300

    systemclock: Clarify comment that described a previous version of the code
    
    Nowadays we are only waking up the head entry waiting if either the head
    entry is unscheduled (which is handled some lines above already), or
    when the head entry specifically is woken up because a new entry became
    the new head entry.
    
    We're not waking up *all* entries anymore whenever any entry in the last
    was unscheduled.

commit 39f8dd00d6b1ed4f43f72a3e22b0b7ab68601523
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Fri May 22 19:28:54 2020 +0300

    systemclock: Get rid of atomic access to clock entry status and use the mutex instead
    
    We already have a mutex in each clock entry anyway and need to make use
    of that mutex in most cases when the status changes. Removal of the
    atomic operations and usage of the mutex instead simplifies the code
    considerably.
    
    The only downside is that unscheduling a clock entry might block for the
    time it needs for the waiting thread to go from checking the status of
    the entry to actually waiting, which is not a lot of code.

commit dbddb5afd8bf2b9f0bc8eaee3ab4a5c5079e9aca
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Fri May 22 18:12:55 2020 +0300

    systemclock: Don't start waiting for a clock id if it was signalled before
    
    Otherwise it can happen that unscheduling a clock id never takes place
    and instead it is waiting until the normal timeout. This can happen if
    the wait thread checks the status and sets it to busy, then the
    unschedule thread sets it to unscheduled and signals the condition
    variable, and then the waiting thread starts waiting. As condition
    variables don't have a state (unlike Windows event objects), we have to
    remember ourselves in a new boolean flag protected by the entry mutex
    whether it is currently signalled, and reset this after waiting.
    
    Previously this was not a problem because a file descriptor was written
    to for waking up, and the token was left on the file descriptor until
    the read from it for waiting.

CC @ystreet