The previously used 'membar' macro does not have 'rax' in its clobber
list. As result, a compiler may not reload the contents of 'rax' after
the setJmp() call and instead 'cache' eax's value. However, 'rax' is
used to pass the jump's value once we perfrom a long jump. Therefore,
it should be part of the clobber list of setJmp().

In fact, GCC 14 started to perform an optimization in this case,
causing Fibril synchronization to fail, as the passed
fibrilResumeValue became 0.

Compare the following code of ContextManager::start()

GCC 13:
3f40d:   e8 2e e8 fd ff          call   1dc40 <Continuation::setJmp()::{lambda(Continuation*)#1}::operator()(Continuation*) const@plt>
3f412:   89 44 24 04             mov    %eax,0x4(%rsp)
3f416:   48 98                   cltq
3f418:   48 89 44 24 08          mov    %rax,0x8(%rsp)
3f41d:   90                      nop

GCC 14:
3f8ea:   e8 81 e2 fd ff          call   1db70 <Continuation::setJmp()::{lambda(Continuation*)#1}::operator()(Continuation*) const@plt>
3f8ef:   90                      nop

As we can see, GCC 14 does not (re-)load eax back to its stack
position after the setJmp().

If we reach this code with fibrilResumeValue == 0, then something went
wrong (as it did with gcc-14, but that is solved in a later commit).

The binary fails if the fibril is synced implicitly over its
destructor. It appears that after membar(doSync()), the base pointer
is wrong, causing the subsequent "reverseStealCount = 0" in
syncWaitFree() to write to unallocate memory. I am not sure yet why,
but this works around the issue.

This also refactors a bit when we take timestamps.

[gitlab-ci] Bump to debian-testing-dev 1.30 and iwyu 0.19

See merge request !414

[gitlab-ci] Bump debian-testing-dev to 1.29

See merge request !413

[gitlab-ci] Bump image to debian-testing-dev:1.28

See merge request !412

add waitfd support, generalize IO sleep_strategy code and use MSG_RING

See merge request !411

In my master's thesis, I described in listing 4.4 an io_uring-based
suspension and notification algorithm, which is slightly different from
what emper does.

The described algorithm does not reset the sleep state if a worker
skips sleeping because of a global sleeper count of less than 0 (line 21).

Emper does always reset the sleep state to SleeperState::Running if
the sleep method returned early (either the worker was specifically
notified or the global sleep count indicated to skip the sleep attempt).

Both variants are sound, but invariably resetting the sleeper count to
running minimizes the windows of useless specific notifications.

However, the assertion in onNewWorkNotification assumes the sleep state
is always SleeperState::Notified if a specific notification is received
through the worker's io_uring.

Emper, resetting the sleep state, introduces a race between the notifier
observing the state as sleeping, setting it to notified, and posting a
notification to the potential sleeper's io_uring.
But the sleeper skips the sleep attempt because the global sleeper count
righteously resetting its state to running while invalidating the
assertion.

Therefore we remove the assertion because it is not invariant.

The WaitfdSleepStrategy did not gather the amount of posted notifications
but the PipeSleepStrategy did.
Move the stats accounting into AbstractIoSleepStrategy so all derived
strategies track the amount of written notifications.

When the custom logic of the IO-based sleep strategies returns
false we already have set the sleeper state to Sleeping and must
reset it.