Tune network retries for slow or congested connections

A longer resource timeout can keep a slow but progressing cache download from falling back to a source build. Until now, however, every failed request still used three fixed retries. Raising the timeout could therefore turn one stalled transfer into up to four long waits, with no way to adjust that tradeoff.

Tuist now exposes the shared Hypertext Transfer Protocol (HTTP) retry policy through two environment variables:

• TUIST_HTTP_MAXIMUM_RETRY_COUNT controls how many retries follow the initial attempt. It defaults to 3, setting it to 0 disables retries, and values above 10 are capped at 10.
• TUIST_HTTP_RETRY_BASE_DELAY_IN_MILLISECONDS controls the initial exponential backoff delay. It defaults to 100 milliseconds and values above 30000 are capped at 30000 milliseconds.

The base delay now correctly starts at 100 milliseconds rather than roughly one millisecond. Each retry doubles the delay and adds up to one base delay of random jitter, helping clients avoid retrying in lockstep after a shared network failure. Individual retry delays never exceed 30 seconds.

Self-hosted operators can now pair a longer resource timeout with fewer attempts, or increase the base delay to spread retries during congestion. Invalid values fall back to the defaults.