Update npm config with `fetch-retry-mintimeout` and `fetch-retry-maxtimeout`

[geriux]

This PR attempts to solve the current errors when installing npm dependencies in CI, mostly happening in the Android jobs with the error:

npm ERR! code ETIMEDOUT
npm ERR! network
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly.  See: 'npm help config'

It increases the following config:

• fetch-retry-mintimeout to 120000
• fetch-retry-maxtimeout to 300000

For comparison in my local setup, the default values are 10000 for fetch-retry-mintimeout and 60000 for fetch-retry-maxtimeout

To test all CI checks should pass.

PR submission checklist:

• [x] I have considered adding unit tests where possible.
• [x] I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

[geriux]

From your comment, I tried that in https://github.com/wordpress-mobile/gutenberg-mobile/pull/6699 and it doesn't work for our issues. When looking for solutions, the most mentioned approaches were to increase fetch-retry-mintimeout and fetch-retry-maxtimeout. For example in this issue from the npm client repo. I also saw other posts like this one.

It appears that fetch-timeout specifies the maximum time npm will wait for a single network request to complete before timing out. Meanwhile, the fetch-retry-mintimeout option sets the minimum timeout value for retry attempts when npm encounters a failed network request, as seems to be the case in our CI environment due to limited network speed/stability.

[geriux]

I'm going to retry all jobs again just to make sure they pass the npm installation step. 🤞

[geriux]

Some of the jobs will fail due to the existing artifacts in CI. I think we could try this approach and see how it performs. What do you think @fluiddot ?

[fluiddot]

Some of the jobs will fail due to the existing artifacts in CI. I think we could try this approach and see how it performs. What do you think @fluiddot ?

Sounds good, the changes won't break the CI jobs so let's try it.

[geriux]

Ok it is still failing 😅 . We should probably fix the CI issues by adding cache to see if it solves this npm failures.

I'll close this for now.

[fluiddot]

@geriux Another option we could try is to reduce the number of parallel connections with maxsockets. Maybe npm is initiating too many requests and the Buildkite instance has some kind of limitation.

[geriux]

@geriux Another option we could try is to reduce the number of parallel connections with maxsockets. Maybe npm is initiating too many requests and the Buildkite instance has some kind of limitation.

Interesting, let's try that!

[fluiddot]

Seems changing maxsockets didn't address the issue 😞. At this point, I think we should investigate the Buildkite instance to avoid connection timeouts.

[geriux]

Seems changing maxsockets didn't address the issue 😞. At this point, I think we should investigate the Buildkite instance to avoid connection timeouts.

Yup, I'm trying one more thing just out of curiosity which is to remove the --prefer-offline flag, since there's no cache at the moment. But yeah we should investigate what's happening with Buildkite instead.