reduce test execution: coreutils::tests::test_tail::*

[sylvestre]

it is currently 12.030s for the longest
see https://app.codecov.io/gh/uutils/coreutils/tests

see:
coreutils::tests::test_tail::test_follow_name_move_retry2 12.030s
coreutils::tests::test_tail::test_follow_descriptor_vs_rename1 12.029s
coreutils::tests::test_tail::test_retry7 10.030s
coreutils::tests::test_tail::test_follow_name_move_retry1 10.029s
coreutils::tests::test_tail::test_follow_name_move2 8.029s
coreutils::tests::test_tail::test_follow_name_move_create2 8.029s
coreutils::tests::test_tail::test_retry4 8.029s
coreutils::tests::test_tail::test_follow_name_multiple 7.541s
coreutils::tests::test_tail::test_retry9 7.018s
coreutils::tests::test_tail::test_follow_descriptor_vs_rename2 6.029s
coreutils::tests::test_tail::test_follow_name_retry_headers 6.029s

Ideally, they should take less a second

[MCozhusheck]

Most of those test are time sensitive and have defined sleep intervals between each retry.
I was able to optimize the timing values to make the tests run significantly faster on my machine (reducing execution time by 60-80% in most cases) while maintaining reliability. However, I can't guarantee these optimized timings would work consistently across different systems and hardware configurations.

Should we go that path or take different approach? Probably having some event emitting and listening synchronization could make this way faster and 100% reliable but I am not sure if it's realistic solution.

[ChrisDryden]

I'm only speaking my own experiences when talking about time issues related to flaky tests and sleeps, but the mental model I have is that (Stability > Time saved) but the goal is to reduce runtime as possible, so if there's a change that will make it faster but more flaky its not worth the tradeoff.

The approach here would be to change the tests in a way that is constantly polling to the output for the test end condition so that in most cases it can terminate quicker. When these optimizations are made you can even increase the timeout duration because in the aggregate the tests will run faster and with a higher stability since most of the time they complete way before the timeout occurs anyways. This can be applied to all tests that fill these characteristics.

Another approach which is more complicated is coming up with a way to simulate the test flakiness, either by running the test many times in parallel or adding load to the system to be able to experiment with changing the implementation to run with less variation. I would recommend going with the other approach first though since its much simpler and ends up with a similar result.