LinuxVersion used the assumption that both strings have the same
amount of dot-separated components.
But this is obviously not always the case.
If we can't compare the two strings further they must been equal so far.

* sleeping workers have decremented the semaphore count before sleeping.
  But if they are notified specifically the semaphore counter is
  decremented excessively
  This results in unnecessary suspension/notifications because the
  counter is out of sync with the actual waiter count.
* waitv expects that the futex size is specified in the futex flags
* wake sleepers using FUTEX_PRIVATE_FLAG
* futex_waitv returns the index of the woken futex -> wake on ret > -1
* add debug output and asserts

A getter not calling sem.wait is needed so we don't call sem.wait twice:
once during Future::cancel() and Future::wait() to obtain the return
value afterwards.

Our only cancellation test case where it is possible that the cancellation
must happen on a specific worker uses a single fiber.
The introduced massCancelOnDifferentWorker() test case uses
workerCount * 5 fibers and actively tries to provoke cancellation on
other workers.

Remember the IoContext where a Future was prepared and submit
the CancelWrapper on the correct Worker using scheduleOn.

Introducing a lock for each specific state greatly simplifies the
algorithm, fixes a race and I expect it to be rather cheap.
The fact that we have to check two conditions before sleeping
and prepare resources dependent on those makes the algorithm
complex and racy.
We skip sleeping if we were notified specifically or the global sleeper
count was less than 0.

If we check our local state first and decrement the global sleeper count
later. We could receive a notification after the decrement which causes
the worker to skip sleeping making the decrement wrong and the whole counter
unsound.

Checking the local state first and mark us as sleeping preparing a
read for the specific pipe has the problem that after the decrement if we
should skip sleeping we have prepared sqes which we should submit needlessly
because we are not actually sleeping.

Ans decrementing the global count first has the same problem as the
first one where the decrement is wrong if we skip sleeping after wards
breaking the counter.

All this is prevented by locking the specific state while we check both conditions.

Change the mechanisms how EMPER achieves the invariant that only the
OWNER of an IoContext is allowed to reap new work notifications from it.
Previously we used the state of the PipeSleepStrategy which proved complex
and error prone.
Now we always check if the completions we are about to reap contain any
new work notifications and if so return early without reaping those.
Now the behavior of reap locked equals the lock-less variants.

Implement notifySpecific by using a worker exclusive thread local
sleepState and pipe.
The sleepState previously waitInflight is no longer a member of IoContext
a thread_local PipeSleepStrategy::SleepState is used instead.
It is safe to use a thread_local object because onNewWorkNotification
is only called by the Owner of the sleepState.
Since others (ANYWHERE, EMPER) must not reap newWorkNotifications from
a workers CQ.

Update the algorithm documentation and other code comments.

* Using SleeperState instead of boolean flags make the code more readable.
* Don't try to notify ourselves resulting in an infinite loop.
* Allocate the worker states cache line exclusive.
* Add debug messages.
* Back off for 1ms when notifying everyone to allow the specific worker
  to wake up.

The SpuriousFutex2Semaphore is able to notify a specific worker
by using two futexes two wait on.

One working like a normal semaphore used for global non specific
notifications via notify() and notify_many().

And a second one per worker which is based on a SleeperState.
To notify a specific worker we change its SleeperState to Notified
and call FUTEX_WAKE if needed.

The FiberHint is needed to decide in the runtime which worker to wake up.
* Hint(Worker, FiberSource::inbox) -> try to notify the specific worker
* Hint(FiberSource::{local,anywhereQueue}) -> notify anyone

The first case is needed because due to the new worker local inbox queues
we must notify the worker of the queue to prevent sleep locks.
The SemaphoreSleepStrategy already has a notifySpecific implementation
but it is very naive badly and we should implement new ones.

The second case is the what the runtime has done before.
Its WakeupStrategy decides how many workers the SleepStrategy should
wake up.

Also remove default CallerEnvironment template parameters to prevent
errors where the CallerEnvironment was forgotten and not passed on a
call side.

The new class is used when specific location of a Fiber is needed
it combines a emper::FiberSource with an workerid_t.
This replaces the hints using TaggedPtrs with IoContext::PointerTags.

IoContext::PointerTags::NewWork{Wsq,Aq} becomes
IoContext::PointerTags::NewWorkNotification.

This function is needed to deal with worker local ressources: io_uring
requests for example.

Each worker now always has a MPSC inbox queue which was already used
in the laws scheduling strategy.
Fibers can be scheduled to a specific worker using the new
Scheduler::scheduleOn method.

Since the inbox queues are now always present we can use a single
FiberSource enum combining AbstractWorkStealingStrategy::FiberSource
and LawsStrategy::FiberSource.

The laws strategy now uses the inbox queues as its priority queues.
With the only differenze that when scheduling to a inbox queue
using the Scheduler::scheduleOn the Fiber lifes only in the inbox
queue and not also simultaneously in a WSQ.

Unrelated code changes made while touching the code anyway:
* Introduce FiberSource::io which hints that a Fiber comes from the
  worker's own CQ.
* Strongly type the fiber's source in NextFiberResult.
* Make all scheduler functions return std::optional<NextFiberResult>
* Cleanup the identation in nextFiberResultViaWorkStealing

Improve log messages

See merge request !311

We commonly use foo=0x1234 in log messages in EMPER.

Log tags should not be longer than 5 characters.

[log] Use system_clock instead of high_resolution_clock

See merge request !309

[TimeoutTest] fix timeout return assertion for linux 5.16

See merge request !310

I could not identify the commit that changes this behavior but
it is reproducible on our bigboxes and my arch system.

According to the 'Notes' section of
https://en.cppreference.com/w/cpp/chrono/high_resolution_clock one
should just use steady_clock or system_clock. Furthermore, the notes
state that with GCC's libstdc++ high_resolution_clock is system_clock,
but for LLVM's libc++ it depends on the configuration (and is
steady_clock). But steady_clock has no to_time_t() member function.

Hence we explicitly uses system_clock now, which always has
to_time_t(), i.e. in libstdc++ and in libc++. This allows us to get
rid of the GLIBCXX (libstdc++) specific code.

Optionally build with libc++

See merge request !307

[meson] Add use_bundled_deps option

See merge request !308

[PipeSleepStrategy] Fix memory_order of atomic.store()

See merge request !306

The memory order of stores must be one of relaxed, release, or
seq_cst. Using 'acquire' with a store is, not allowed.

[IoContext] fix types when tracking request in flight

See merge request !304

The count used to track the requests is unsigned and negating it before
using it as long does not what we want.

Fixes: 799e5055

[UnblockOnMainActorTest] adjust workload to log level

See merge request !303

The UnblockOnMainActorTest regularly timeout in our CI
which looks to be a regular timeout because I could easily reproduce
the timeout on fauibig03.

Hopefully this change fixes regular timeouts like
https://gitlab.cs.fau.de/aj46ezos/emper/-/jobs/506757
in the CI and only leaves real faulty timeouts.

[meson] add boost as dependency

See merge request !301

I setup a new development environment and emper did not compile because
emper::io::Stats use the circular_buffer provided by boost.
Boost was not installed and our build-system failed to detect it.

This change adds the header-only boost dependency to emper.
https://mesonbuild.com/Dependencies.html#boost
The header-only dependency is enough to build emper default configuration.

When linking against boost is required we use the 'modules' karg.

[Dispatcher] replace deprecated pthread_yield with sched_yield

See merge request !302

Compilation with gcc on ubuntu 21.10 fails because pthread_yield is
apparently deprecated and should be replaced with sched_yield.

gcc --version
gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0

properly cancel future callbacks

See merge request !297

* Document data races of a future's state.
* Get and set a Future's state only through methods. This helps to
  add possibly needed atomic operations.
* Use atomics to get/set cancel and prepare state in IO_SINGLE_URING vaiant
* Add more IO debug messages
* Use the BPS of Futures with callbacks similar to those of forgotten
  ones to signal their preparation. The preparation mark the
  last moment where the Future is used in EMPER and after that the memory
  can be dropped.
  ATTENTION: This means not that the used resources of the IO request
  can be dropped. The kernel may still use a supplied buffer for example.
* Fix Future chain cancellation in SubmitActor

Currently canceling Futures would never happen because we
issued the cancel request only with the pointer of the future.
This works more by coincidence than by design because
the PointerTags::Future tagged onto the submitted future pointer is 0.

This does not work for callbacks because they are tagged with a
PointerTags != 0 and they don't use their callback pointer rather
than the future pointer.

Fix this by exporting the tagging from IoContext::prepareFutureChain
into IoContext::createFutureTag and use this when submitting a cancel
sqe.

Warn the user that they have to manually take care of the memory safety
of the callback because we can not await the callback in Future::cancel.

Add a test case to CancelFutureTest.