Being able to control the current time in the tests

[da-kami]

As mentioned #2282 we might want to add restrictions to allowing a settlement_event_id for rollover. This would mean that our actor tests start depending on the current time, which is not a trivial problem to solve.

The proper way to achieve stable tests would be to make time deterministic (that way we could also test edge cases). This would mean that we would have to define a test setup (or over application setup) that makes it possible to control time (i.e. calls to now).

One problem to solve here, is that the "controlled" time would have to be globally available to the system. We can write unit tests where we supply now (as done in model::cfd) but in the actor tests we would have to control the time at an application level.

[da-kami]

One way to achieve this would be a configuration outside of our application by using something like https://github.com/wolfcw/libfaketime

If we want to to go this way we would have to create a more extensive test setup outside of the application and test code. I did not think this through too much - it is not trivial and controlling it from the test might be even harder (i.e. not only setting it to one specific time before running one test, but manipulating the current time from within the test, which would could be very useful to have).

[da-kami]

We could add a TimeProvider to the ActorSystem that is passed down to all components that need it. We would have to ensure that only one instance exists (i.e. use an Arc). We could then control the TimeProvider in the tests.

Challenges around this are related to using such a TimeProvider over the boundaries of multiple crates.
The production code might also get unnecessary complex because we would have to pass this time provider to e.g. every Cfd upon creation in the database (...)

[klochowicz]

I haven't looked into these solutions, but ages ago I created a PR for itchysats that did exactly what we want - will try to dig it up for evaluation.

[da-kami]

Looking forward to seeing it.
I think the biggest challenge will be activating it over crate boundaries. If this was from a time where we only had one crate I might not be sufficient anymore.

[da-kami]

https://blog.iany.me/2019/03/how-to-mock-time-in-rust-tests-and-cargo-gotchas-we-met/ describes various challanges.

They have tried to configure conditions using cfg(test) and feature flags, but to get this right over the boundaries of multiple crates seems to be quite hard. The problem is that when we run tests in e.g. daemon-tests and depend on model then cfd(test) won't be active in model.

They recommend using RUSTFLAG instead. I have not looked into this in detail, but I think this would also require us to adapt how we run the tests which I would like to avoid.