feat: Add resumable downloads with HTTP Range support for weak networks

[Renkai]

Summary

This PR adds resumable download capability using HTTP Range requests to significantly improve download reliability on weak or unstable networks.

Problem

Currently, uses 's which has these limitations:

• Only 3 retry attempts
• 10-20 second retry delays
• Restarts download from 0% on every failure

On weak networks, this means a 100MB file that fails at 90% downloaded will restart from scratch, wasting bandwidth and time.

Solution

Implemented a new function that:

Key Features

• ✅ HTTP Range requests - Resumes from last successful byte if download fails
• ✅ 5 retry attempts (up from 3)
• ✅ Exponential backoff - 10s to 120s retry delays
• ✅ Progress tracking - Shows download speed and percentage
• ✅ 60s socket timeout - Better control over network timeouts
• ✅ Automatic partial file detection - Detects and resumes interrupted downloads

Technical Details

• Uses undici (already in dependencies) for HTTP requests
• Supports both HTTP 200 (full) and 206 (partial content) responses
• Validates server support for Range requests
• Falls back to full download if Range not supported
• Progress logged every 10MB

Example Behavior

Before:

Attempt 1: 0MB → 90MB → timeout ❌
Attempt 2: 0MB → 85MB → timeout ❌  
Attempt 3: 0MB → 88MB → timeout ❌
Failed after 3 attempts

After:

Attempt 1: 0MB → 90MB → timeout
Attempt 2: Resume from 90MB → 95MB → timeout
Attempt 3: Resume from 95MB → 100MB ✅
Success!

Testing

The implementation has been:

• Type-checked against the existing codebase
• Follows the same error handling patterns as existing code
• Maintains backward compatibility with GitHub releases API
• Works with existing checksum validation

Files Changed

• • New module with resumable download logic
• • Updated to use resumable downloads

Impact

This change will particularly benefit:

• Users in regions with unstable internet connections
• CI/CD pipelines running in network-constrained environments
• Scenarios where GitHub releases download is slow or unreliable

No breaking changes - the public API remains the same.

[Renkai]

The description is generated by Claude, I made this PR because the download often fails after consumed all the retry times, I think if we can save the progress of the last try, it may eventually get finished after several tries.

[eifinger]

Thank you for your contribution!

This adds quite a lot of complexitly. I want to be sure the benefits outweigh the added maintenance overhead.

1. Have you considered raising this PR in https://github.com/actions/toolkit/blob/main/packages/tool-cache/README.md ?
2. Have you verified that your changes fix the issues you have observed?