fix: resolve repeatable test suite breakage with ioredis 4.19.0+

Created by: Rua-Yuki

This PR resolves failures in the repeatable job test suite brought about by upgrading ioredis to 4.19.0+, as mentioned in the comments for https://github.com/OptimalBits/bull/commit/6fe29283e85a64c07586fe8463de065ae7480513 and https://github.com/OptimalBits/bull/issues/758.

The precise change in ioredis which yields breakage is the introduction of a new script cleanup helper interval, intended to periodically purge a dictionary used for tracking scripts loaded for the purpose of pipelining. See here, or observe the excerpt below.

      this._addedScriptHashesCleanInterval = setInterval(() => {
        this._addedScriptHashes = {};
      }, this.options.maxScriptsCachingTime);

Nothing is intrinsically wrong with what ioredis has done here. We only see breakage within the Bull tests due to a chance interaction with the new cleanup interval, brought about by extremely taxing usage of sinon.

During the test setup phase, sinon is used to spoof timing functions, applying a base time equivalent to the Unix epoch. https://github.com/OptimalBits/bull/blob/dbc08f23e93147c5c6b2b04fdad5a0c92d746654/test/test_repeat.js#L21

Within some tests, the same sinon clock is advanced by massive amounts at once (over 47 years). https://github.com/OptimalBits/bull/blob/dbc08f23e93147c5c6b2b04fdad5a0c92d746654/test/test_repeat.js#L200-L201

These clock.tick(...) calls result in a punishing number of executions (around 25 million) of the aforementioned interval. This all takes quite a while, leading to timeouts in the end, and ultimately being the root of test failures.

The solution for this thankfully appears to be a simple one: merely swapping out clock.tick with clock.setSystemTime.