fix: use non-resumable downloading for actor bundles to avoid CI test flakyness

[hanabi1224]

Summary of changes

To mitigate #5287
The previous effort did not fully fix the issue

Changes introduced in this pull request:

• use non-resumable downloading for actor bundles to avoid CI test flakyness
• limit max concurrent downloading jobs

Reference issue to close (if applicable)

Closes

Other information and links

Change checklist

• I have performed a self-review of my own code,
• I have made corresponding changes to the documentation. All new code adheres to the team's documentation standards,
• I have added tests that prove my fix is effective or that my feature works (if possible),
• I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

[LesnyRumcajs]

Why 4 in particular? And not 3 or 10?

[hanabi1224]

I think any value between 2-8 is fine, 4 is somewhere in the middle.

[LesnyRumcajs]

Why 9 is not fine?

[hanabi1224]

Larger number is faster but more error-prone. Previously, all tasks run in parallel and the test was quite flaky

[hanabi1224]

Looking at the time cost of the test, 4 makes it more stable and still fast

[LesnyRumcajs]

We can try, but I'm not 💯 convinced. I'd rather we have a deterministically correct and working solution. This seems like reducing error probability from an unknown chance to another unknown (but likely smaller) chance, while always paying the price of reduced performance (slower startup for fresh nodes).

[hanabi1224]

We've been using the same logic for RPC snapshot test and it's much more stable, the only notable difference is, actor bundle uses Github assets primarily while RPC snapshot test uses DO space CDN.

[hanabi1224]

I believe it's a common practice to limit max concurrent downloads, e.g. the author uses 8 in https://patshaughnessy.net/2020/1/20/downloading-100000-files-using-async-rust
And I think the number really depends on the network environment between client and remote server