tests: speed up ordering tests by using simulation clock

[carlaKC]

Pulling this out of #301 to speed up the tests so we don't have to wait ~1min for each run, this change gets full test suite back down to ~5s.

[f3r10]

it looks like only 19 payments are generated. And the correct expected payment is
let expected_payment_list = vec![ pk1, pk2, pk1, pk1, pk1, pk3, pk3, pk3, pk4, pk3, pk2, pk1, pk4, pk2, pk2, pk2, pk2, pk1, pk3, ];

[carlaKC]

I think that we have a race here - this passes on my machine and is failing here.

Pushed a change to make this 12 payments, so that we definitely hit the target count - diff was trivial so didn't use a fixup.

DId a quick flake test here with:
for i in {1..100}; do echo "Test run $i"; cargo test test_deterministic_payments_events_random || break; done

And I run into an issue where the second last (index 10) payment is either pk2 or pk3. The only test change that I can see breaking this is the clock speedup, which makes me think we may have a rounding issue somewhere in the determinism change that needs tie-breaking?

[f3r10]

I found the issue.
The problem is with the rounding of the wait_time.
There are times (after 1000 times, probably) that instead of getting 1.543701036s, the wait_time is 1.495485804s
Rounding 1.543701036s is 2, and rounding 1.495485804s is 1. Becuase of this reason the determined order fails.

I think one possible solution would be to round to the first decimal place.
1.543701036s -> 1.5
1.495485804s -> 1.5

WDYT?

[f3r10]

the solution that I found was to round the wait_time to one decimal.

fn round_duration_to_one_decimal(duration: Duration) -> f64 {
    let millis = duration.as_millis();
    let rounded_millis = (millis + 50) / 100 * 100;
    rounded_millis as f64 / 1000.0
}