Pretty much all timer start event tests increase the engine time to test
the timer scheduling. These tests can all suffer from unwanted race
conditions becaue the timer is scheduled in a post-commit task. There is
no clear way to await for this post-commit task to be executed, except
for awaiting the engine to reach the end of the log.

Since we generally only want to time travel in tests when there is
something related to the timer scheduling, it makes sense to hide this
in the `increaseTime` method of the EngineRule.

Also note that this only matters when the streamprocessor is currently
processing. If the engine is paused, the hasReachedEnd method cannot be
called because the relevant actor is also paused.

Co-authored-by: Remco Westerhoud <remco@westerhoud.nl>
Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>

If you want to increase the time, we're now using the streamprocessor
directly. But in the shouldAvoidTriggeringMultipleTimes test case, the
engine was stopped before increasing the time. When the engine is
stopped, the stream processor is removed.

However, this test just wants to verify wht happens if the scheduled
timer triggers and the upcoming due date would also be in the past. That
can be achieved as well by pausing the engine instead of stopping it
completely.

Note that when the engine is paused, we don't have to reset the
recording exporter (on restart it would re-export all records again).

Co-authored-by: Remco Westerhoud <remco@westerhoud.nl>
Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>

Co-authored-by: Remco Westerhoud <remco@westerhoud.nl>
Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>

Now that the EngineRule.increaseTime can guarantee that timers are
scheduled before time traveling, we no longer need Awaitility to
repeatedly check that the timer triggered.

Co-authored-by: Remco Westerhoud <remco@westerhoud.nl>
Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>

This test was flawed as it creates a timer with a duration of 100ms. Then it continues to verify it has been triggered after 1 second.

This worked because the engine increased it's time. This happened before the timer was scheduled so in reality the timer would trigger after 1.1 seconds. With the change in the increase time method to wait until the engine is idle before increasing the time this broke, as the timer would now be scheduled for the 100ms mark as expected.