Concurrently download components of a toolchain

[FranciscoTGouveia]

As of now, each component of a toolchain is downloaded sequentially, leaving room for performance improvements.
This is particularly notorious when considering interleaving downloads with installation, as discussed in #731.

Following the work made in #4426, as the DownloadTracker is now indicatif-based, doing the progress reporting for concurrent downloads is much easier.
As such, this PR comes to enable downloading different components concurrently (possibly closing #3018).

Performance-wise, benchmarks using hyperfine showed a small (1.1x) speedup -- which doesn't seem noticeable but lays the foundations for a future PR to interleave the download with the installation (of components).
The benchmarks were ran 50 times (with 5 warmup runs) over a 50 Mbps connection, each downloading an entire toolchain.

Many thanks to @rami3l and his PR for refactoring part of the test suite for the purpose of this PR.

[FranciscoTGouveia]

For reference, the current download of components (sequential) looks like this:

... and the changes introduced by this PR go like this:

Please note that both animations were sped up and they are not meaningful for comparing performances.

[FranciscoTGouveia]

After my investigation stemming from this comment, I have concluded that the changes presented on this PR are not consistent with the previous behavior of displaying a progress bar during the installation of the component.

Would this be necessary, especially considering that the next step will be to interleave the downloads with the installation?

[rami3l]

I have concluded that the changes presented on this PR are not consistent with the previous behavior of displaying a progress bar during the installation of the component.

Would this be necessary, especially considering that the next step will be to interleave the downloads with the installation?

@FranciscoTGouveia No, I don't think it is necessary for that part of the behavior to stay unchanged, as you have already mentioned. Of course, if it is easy to add it back, then it might still be interesting to do so.

[FranciscoTGouveia]

Thank you for all the reviews comments.
Before anything I would like to apologize for not explaining my questionable decisions in the PR description from the start.
I will definitely have this in mind in my future contributions.

Additionally, I would like to highlight one point:

• The downloads are being executed using .buffered() rather than .buffer_unordered(). A similar situation arose here, however, in this case, the speedup is somewhat despicable (only a 1.1x speedup). Additionally, making this change would change the order that the installations are made in, which I think is unnecessary for this PR. In a future contribution aiming to interleave the downloads with installations, if the installation process is modified, we can revisit this idea.

[rami3l]

This is looking much better to me! Many thanks @FranciscoTGouveia for the work and @djc for a second round of review :)

I've left just a final nit but otherwise I believe this PR is quite ready to be merged 🎉

[djc]

(Also, CI failures...)

[FranciscoTGouveia]

I believe it was a spurious failure.
All comments have now been addressed, and the CI is passing :)