feat: Add additional auto advance time controls (#509)

* feat: Add clock.setTickMode to configure auto advancing time after clock is created

This adds a `setTickMode` method to the Clock to allow developers to
configure whether time should auto advance and what the delta should be
after the clock has been created. Prior to this commit, it could only be
done at creation time with `shouldAdvanceTime: true`.

* feat: Add additional auto advance time controls

TL;DR This adds a new mode for automatically advancing time that moves
more quickly than the existing shouldAdvanceTime, which uses real time.

Testing with mock clocks can often turn into a real struggle when dealing with situations where some work in the test is truly async and other work is captured by the mock clock.

In addition, when using mock clocks, testers are always forced to write tests with intimate knowledge of when the mock clock needs to be ticked. Oftentimes, the purpose of using a mock clock is to speed up the execution time of the test when there are timeouts involved. It is not often a goal to test the exact timeout values. This can cause tests to be riddled with manual advancements of fake time. It ideal for test code to be written in a way that is independent of whether a mock clock is installed or which mock clock library is used. For example:

```
document.getElementById('submit');
// https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
await waitFor(() => expect(mockAPI).toHaveBeenCalledTimes(1))
```

When mock clocks are involved, the above may not be possible if there is some delay involved between the click and the request to the API. Instead, developers would need to manually tick the clock beyond the delay to trigger the API call.

This is different from the existing `shouldAdvanceTime` in the following
ways:

`shouldAdvanceTime` is essentially `setInterval(() => clock.tick(ms), ms)` while this feature is `const loop = () => setTimeout(() => clock.nextAsync().then(() => loop()), 0);`

There are two key differences between these two:

1. `shouldAdvanceTime` uses `clock.tick(ms)` so it synchronously runs all timers inside the "ms" of the clock queue. This doesn't allow the microtask queue to empty between the macrotask timers in the clock whereas something like `tickAsync(ms)` (or a loop around `nextAsync`) would. This could arguably be considered a fixable bug in its implementation
2. `shouldAdvanceTime` uses real time to advance the same amount of real time in the mock clock. The way I understand it, this feels somewhat like "real time with the opportunity to advance more quickly by manually advancing time". This would be quite different: It advances time as quickly possible and as far as necessary. Without manual ticks, `shouldAdvanceTime` would only be capabale of automatically advancing as far as the timeout of the test and take the whole real time of the test timeout. In contrast, `setTickMode({mode: "nextAsync"})` can theoretically advance infinitely far, limited only by processing speed. Somewhat similar to the [--virtual-time-budget](https://developer.chrome.com/docs/chromium/headless#--virtual-time-budget) feature of headless chrome.

In addition to the "quick mode" of `shouldAdvanceTime`, this also adds
the ability to modify the initially configured values for
shouldAdvanceTime and advanceTimeDelta.

Author: atscott

README.md

@@ -146,6 +146,12 @@ setTimeout(() => {
 }, 50);
 ```
 
+In addition to the above, mocked time can be configured to advance more quickly
+using `clock.setTickMode({ mode: "nextAsync" });`. With this mode, the clock
+advances to the first scheduled timer and fires it, in a loop. Between each timer,
+it will also break the event loop, allowing any scheduled promise
+callbacks to execute _before_ running the next one.
+
 ## API Reference
 
 ### `var clock = FakeTimers.createClock([now[, loopLimit]])`
@@ -176,6 +182,29 @@ The following configuration options are available
 | `config.shouldClearNativeTimers` | Boolean     | false                                                                                                                                                                                                                          | tells FakeTimers to clear 'native' (i.e. not fake) timers by delegating to their respective handlers. These are not cleared by default, leading to potentially unexpected behavior if timers existed prior to installing FakeTimers.                                   |
 | `config.ignoreMissingTimers`     | Boolean     | false                                                                                                                                                                                                                          | tells FakeTimers to ignore missing timers that might not exist in the given environment                                                                                                                                                                                |
 
+### `clock.setTickMode(mode)`
+
+Allows configuring how the clock advances time, automatically or manually.
+
+There are 3 different types of modes for advancing timers:
+
+-   `{mode: 'manual'}`: Timers do not advance without explicit, manual calls to the tick
+    APIs (`jest.advanceTimersToNextTimer`, `jest.runAllTimers`, etc). This mode is equivalent to `false`.
+-   `{mode: 'nextAsync'}`: The clock will continuously break the event loop, then run the next timer until the mode changes.
+    As a result, tests can be written in a way that is independent from whether fake timers are installed.
+    Tests can always be written to wait for timers to resolve, even when using fake timers.
+-   `{mode: 'interval', delta?: <number>}`: This is the same as specifying `shouldAdvanceTime: true` with an `advanceTimeDelta`. If the delta is
+    not specified, 20 will be used by default.
+
+The 'nextAsync' mode differs from `interval` in two key ways:
+
+1.  The microtask queue is allowed to empty between each timer execution,
+    as would be the case without fake timers installed.
+1.  It advances as quickly and as far as necessary. If the next timer in
+    the queue is at 1000ms, it will advance 1000ms immediately whereas interval,
+    without manually advancing time in the test, would take `1000 / advanceTimeDelta`
+    real time to reach and execute the timer.
+
 ### `var id = clock.setTimeout(callback, timeout)`
 
 Schedules the callback to be fired once `timeout` milliseconds have ticked by.