Reconsider how aggressive the test suite is #85
Description
A good test is often only concerned with the behavior of its own, self-contained slice of the world. For our tests, that would normally mean processing filesystem events given to us by the kernel, checking all the invariants we need to uphold to deliver them correctly through our API from the kernel.
However, there have been some test cases which are only reproducible (1, 2) when the system is under heavy load.
Because we want to test that we behave as correctly as we can in those cases, we need to put the system under test into an uncomfortable position. For example, some of our tests rapidly issue a thousand filesystem events before checking some postcondition on each event. This has the obvious downside of bumping into issues outside of our direct control, like the kernel dropping events or guix tests failing for probably similar reasons (the events were never received by this library).
It's not our job to test that the kernel reports every event. In some cases, it can't or won't. But the tests that require a system under load will get mixed results on different platforms and kernels, or even differently-configured environments on the same platform.
The tests are nevertheless still valuable under some circumstances.