make sleep semaphore threshold configurable

See merge request i4/manycore/emper!378

increase the sleep semaphore threshold

See merge request i4/manycore/emper!377

Pulse: initial pulse evaluation commit

See merge request i4/manycore/emper!376

fsearch: add more fine grained control about the used fiber throttles

See merge request i4/manycore/emper!375

Also remove the negation of the condition (!> equals <=).

We currently use the semaphore of our sleep strategy very greedy.
This is due to skipping the semaphore's V() operation if we are sure
that it does not kill our progress guaranty.

When scheduling new work from within the runtime we skip the wakeup if
we observe nobody sleeping. This is fine in terms of progress and
limits the amount of atomic operations on global state to a minimum.

Using a threshold of 0 (observe nobody sleeping) however introduces a
race between inserting new work and going to sleep which harm the
latency when the worker goes to sleep and is not notified about the
new work.

This race is common and can be observed in the pulse micro benchmark.
A emper with a threshold of 0 shows high latency compared to using
an io-based sleep strategy or when increasing the threshold.

$ build-release/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1721970116.425

$ build-increased-sem-threshold/eval/pulse | python -c "<calc mean"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000023942.15

$ build-pipe-release/eval/pulse | python -c "<calc mean>
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000030557.0861111

$ build-pipe-no-completer/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000021514.1805556

I could not measure any significant overhead due to the more atomics
on my 16 core machine using the fs-eval on a SSD.

$ ./eval.py -r 50 -i emper-vanilla emper-inc-sem-threshold emper-pipe emper-pipe-no-completer
...
$ ./summarize.py results/1599f44-dirty-pasture/<date>/ -f '{target}-{median} (+- {std})'
duration_time:u:
emper-vanilla-0.202106189 (+- 0.016075981812486713)
emper-inc-sem-threshold-0.2049344115 (+- 0.015348506939891596)
emper-pipe-0.21689131 (+- 0.015198438371285145)
emper-pipe-no-completer-0.1372724185 (+- 0.005865720218833998)

add io synchronous option

See merge request i4/manycore/emper!373

Eventfd's does not support seeking. This is also invalid code:

int main() {
    int64_t b = 42;
    int efd = eventfd(0, 0);
    if (efd < 0) err(EXIT_FAILURE, "creating eventfd failed");
    ssize_t res = pwrite(efd, &b, sizeof(b), 0);
    if (res != sizeof(b)) err(EXIT_FAILURE, "pwrite to evfd failed");
}

When EMPER is build with -Dio_synchronous each Future will be
completed synchronously when calling Future::wait().

io: improve recursive_directory_walk

See merge request i4/manycore/emper!374

* Add optional throttle Semaphore pointer to limit the number
  of spawned fn as well as directory walk fibers
* Use const references to the passed functions instead of values
* fsearch: Use max_running as fn and recursion throttle

[EchoServers] improve the callback based echoserver

See merge request i4/manycore/emper!371

* Pass the IO results on the stack instead of storing them in the
  client object.
* Terminate the runtime on quit to print stats.
* Free Client objects.

Run clang tidy in parallel

See merge request i4/manycore/emper!372

[tests] Infer test name from first test source file

See merge request i4/manycore/emper!370

add assert message in future callback

See merge request i4/manycore/emper!369

This also fixes a bug in
	 source = test_dict['source'][0]
so the source(s) used for the test was always only the first source
file. I did/does not matter, as we do not have tests that span
multiple source files (and I am not sure if we ever will have).

Add a message to help investigate CI failures for single-uring
configurations like:
https://gitlab.cs.fau.de/i4/manycore/emper/-/jobs/574828

[meson] Add build_only_emper_dep option

See merge request i4/manycore/emper!368

[AbstractWorkStealingScheduler] assert in runtime system in pushBottom

See merge request i4/manycore/emper!367

io: do not use IO_FORGOTTEN_FUTURES_SKIP_CQE on linux <= 5.17

See merge request i4/manycore/emper!366

Apparantly my assumption that io_uring ignores unknown cqe flags is
wrong. And io_uring < Linux 5.17 completes forgotten futures with
-EINVAL.

Fixes: e140759d

[AbstractWorkStealingScheduler] Emit warning if overflow queue is used

See merge request i4/manycore/emper!365

incorporate new io_uring features

See merge request i4/manycore/emper!364

We can not deal with cqes for forgotten Futures and not creating them
prevents the kernel and userspace overhead introduced by them.

LinuxVersion::compare reported two versions as equal if it could
find a new '.' in the first version but not in the second.
But this is clearly wrong because it skips comparision of the valid last
part.

The comparision 5.16.12 >= 5.18 returned true because compare
reported the version as equal after comparing the first parts and
finding a second '.' in the first but not the second.

Fix this behavior by marking the current position as the last but
do not skip its comparision.

Add tests for the desired behaviour.

Linux 5.18 introduces IORING_REGISTER_RING_FDS with
e7a6c00dc77aedf27a601738ea509f1caea6d673.

Registering the io_uring's fd prevents having to look it up for each
io_uring_enter call reducing contention on the process file table.
Jens Axboe reports good results in his fio based benchmarks and
I see no reason for EMPER to not register the io_uring fds, especially
because we never pass or share rings.

Do not register the global io_uring since it is shared in the SINGLE_URING
case or it is passed by the main thread to the completer thread breaking the
assumption liburing has about the registered io_uring fd.

Liburing 2.2 and Linux 5.18 support IORING_REGISTER_RING_FDS, preventing
the fget(ring_fd) overhead for each io_uring_enter call, as well as
IORING_OP_MSG_RING, greatly simplifying the IO-based sleep strategy code.