Feature: Coordinated chunk splitting for multiple idle workers (wait-and-split)

[SuperCoolPencil]

Description

Currently, when a worker becomes idle, it blindly splits the largest available chunk in half. If multiple workers become idle at roughly the same time, this sequential "half-splitting" leads to suboptimal, skewed chunk sizes.

Example Scenario:
Imagine you have a download where 100 MB is pending and 3 workers become idle.
Under the current system, the sequential blind splitting results in a skewed distribution of chunk sizes: 12.5 MB, 12.5 MB, 25 MB.

The Optimal Approach:
The optimal split for 3 workers tackling 100 MB should be an even distribution: 33 MB, 33 MB, 34 MB.

Proposed Solution

Instead of immediately splitting a chunk in half whenever a single worker becomes idle, we should explore a "wait-and-split" strategy:

1. Debounce / Batching: Introduce a mechanism to wait briefly and allow multiple workers to become idle before reallocating work.
2. Coordinated N-way Splitting: When multiple idle workers are batched together, divide the remaining payload evenly among them (e.g., dividing by N instead of blindly halving sequentially).
3. This will ensure a much more balanced distribution of work, preventing workers from ending up with tiny chunks while others still have large ones.

[SuperCoolPencil]

An additional benefit to this coordinated "wait-and-split" strategy is how it mitigates tail-latency risks from irregular connection speeds.

In a typical multi-connection download, it's fairly common for a single worker to unexpectedly slow down (e.g., due to temporary packet loss, routing anomalies, or server-side throttling). Having multiple workers simultaneously degrade is much rarer.

If we use the blind sequential splitting approach and end up with heavily skewed sizes—for instance, 12.5 MB, 12.5 MB, 25 MB, and 50 MB—and the worker handling the massive 50 MB chunk happens to be the slow one, that single chunk becomes a massive bottleneck that delays the entire download's completion.

By taking a brief moment to batch idle workers and evenly distribute the payload (e.g., 33 MB, 33 MB, 34 MB), we minimize the maximum chunk size assigned to any single worker. This ensures that no single worker is disproportionately burdened, significantly reducing the impact that one slow connection can have on the overall time-to-completion.

[SuperCoolPencil]

PS: this is a random thought i had when i made an error while doing leetcode

[bladeacer]

Does one spawn and manage goroutines for this? Would this tie itself to number of available CPU cores or just goroutines?