reconsider 75% drop test

In #148, we have tentatively disabled 75% drop tests, because we have started to see the tests fail due to no longer retransmitting packets excessively. Now, the most severe test is 50% drop ones.

However, I think we'd need to have tests that cover a severely congested network. Therefore, listing some thoughts on how we might want to proceed:

* Instead of using a PRNG that generates each loss event as independent events, we might want to use a loss generator that drops like X of every Y packets.
* We might want to record the distribution of times being spent for each loss rate. Current approach just calls out test failure if any of the repetitive tests does not finish within a predefined time. That means that it is at the moment impossible to detect mild regressions.

Start by reading issue #148 and the existing 50% drop tests to understand how loss events and timeout-based completion are currently handled. Compare the proposed loss-generation and timing-distribution approaches, then define completion around coverage of severely congested networks and detection of mild regressions.

Written by the indexing model from the issue text.