Add retry.backoffLimit option

[fvanwijk]

I saw in the source code that the retry backoff function is hardcoded and exponential. However, I wanted to customize it.
Fortunately I also found the open issue addressing this limitation.

To start simple, I added a backoffLimit so that you can cap the delay that is exponentially growing. After 5 or so retries the delay becomes so large that the user will give up anyway.
Setting the limit to for example 1000 in combination with 60 retries will change the behavior into polling for 1 minute (my use case).

I had some trouble testing the delay because the calculate function is private and I didn't find a way to extract this information from the ky instance or response.
So I did some perf measurements to test the delays.

If you are happy with the PR so far, I will implement the calculateDelay option too.

Fixes #389

[sindresorhus]

CI is failing

[fvanwijk]

Thanks for the review.

I must say that testing the delay of the retries a bit hard. You probably also know this, because the delay wasn't initially tested anyway.
Currently the test depends on a quick execution time, but if you run the test on a slow machine it might fail. In my opinion no test is better than a flaky test, so we should delete it.
Or are there ways to test the delay that I don't know of?

[sindresorhus]

Maybe check process.env.CI and increase the number a bit then?

[sindresorhus]

You also need to add the docs to the readme.

[fvanwijk]

I updated the tests to use the Node 14 Performance API (instead of LTS).

By the way, it would be nice if CI runs automatically on push. Now the feedback cycle is pretty slow.

[sindresorhus]

By the way, it would be nice if CI runs automatically on push.

I agree, but GitHub forces me to push this button each time.

[sholladay]

GitHub forces me to push this button each time

That can be changed in the repository settings under Actions > General

[sindresorhus]

@sholladay I'm aware, and I did for this repo. But I have 1000+ repos. I cannot do it manually on all of them.

[fvanwijk]

It looks like the new test that depends on timing makes the test suite flaky. I doubt whether it is a good idea to keep the test. Removing it altogether might be the right thing to do.

[fvanwijk]

@sindresorhus In the mean time there haven't been any activity for about a month. Any suggestions how to follow up? Changes needed or complete the PR?

[sindresorhus]

Thanks. Sorry for the delay. I must have missed the notification.

[fvanwijk]

This PR had flaky tests, so I increased the test timeout offsets. Maybe it is fixed in #484, so we could decrease (set to 0?) the allowedOffset.