- some tests are notoriously flaky
- increase resource limits for the testsuite to allow stronger stress tests
- provide a "quick" variant of BufferProviderLoad_test with lowered requirements
Furthermore, investigate test scaffolding in `DummyBuilderContext`,
which was broken due to the clean-up in `DiagnosticOutputSlot`.
It seems that only some placeholder instances are required here,
so that we might be successful with just instantiating the `UnimplementedConnection`
__TODO__: need to supply slightly more implementation into the latter,
so that we're able at least to ''create'' such a connection stub.
Set ulimit -v setting to 8 GiB (setting is given in kbyte)
Otherwise it is not possible to start 100 Threads.
This is surprising, because the actual memory usage of the tests in question
are minuscule and also TOP does not show any significant memory peak when running the test.
this is strange; we need to crank up the VSize to 6 GiB
to get the 5 massively multithreaded tests to run.
I checked those tests with valgrind and can not see
any such huge allocation
On my slow laptop some tests fail because of timeouts under
valgrind, going to 55/60 seconds should be sane.
Fixing an undiscovered bug ignoring timeout configs in test.sh.
