Migrate away from fake_time

[jonasfj]

Instead we'll have:

• clockControl which can be used to elapse time within testWithProfile
• Whenever you want a delay that is affected by clockControl you can use:
  • Future.timeoutWithClock in place of Future.timeout
  • clock.delayed in place of Future.delayed

This way, a timeout or delay that is used to handle an I/O operation that doesn't complete and use Future.timeout (or Future.delayed).

While a delay or timeout that is used to schedule something after a certain delay can used clock.delayed (or Future.timeoutWithClock).

One of these can be artificially accelerated with clockControl other can't.

If you accelerate a 300ms timeout that throws an error if an I/O operation doesn't complete in 300ms, then it's hard to write a test where the I/O operation succeeds.

If you don't accelerate a delay where you're waiting an hour before rescheduling a task, then tests will take forever to run.

Hence, we have normal timeout / Future.delayed, and we have clock.delayed and Future.timeoutWithClock, which are controlled with clockControl.

[isoos]

The new functions seem good to me, however the naming could be more consistent.

How about:

• Future.timeoutWithClock -> Future.controllableTimeout, because (a) there is no clock provided to the method, and (b) the control of the timeout is outside of the arguments.
• Clock.delayed -> top-level delayedFuture(Duration delay) method, as there is very little need extend it on the clock object, is there? We are not using the instance of it.

[jonasfj]

• Future.timeoutWithClock -> Future.controllableTimeout, because (a) there is no clock provided to the method, and (b) the control of the timeout is outside of the arguments.
• Clock.delayed -> top-level delayedFuture(Duration delay) method, as there is very little need extend it on the clock object, is there? We are not using the instance of it.

I could be down for using controllableDelay and controllableTimeout.

But clockControl also changes clock, so I figured it might be fine to treat it as an extension of clock.

Logically, I think we want ClockController.elapse to advance these futures and the clock at the same time, which is why I figured clock.delayed was a good term.

I'm not sure I like Future.timeoutWithClock, but we can always rename and refactor.