Interleave downloads with installations when downloading a toolchain

[FranciscoTGouveia]

Continuation of #4436.

This change aims to speed up the overall performance of the rustup [toolchain] install command by allowing the installation of a component to start immediately after its download completes.
This approach is particularly beneficial for slower connections, as it enables installations to progress in parallel with ongoing downloads -- so by the time all downloads are finished, all installations should be completed as well.

NB: This PR is not yet ready for review. I believe this change should be backed by benchmarks and user feedback before moving forward. I’ll share those here in the next couple of days.

[FranciscoTGouveia]

As noted in the opening message of the PR, I now present some benchmarks that will enable us to move forward with this change.
As stated before, this will bump the install and update commands' performance, as when the downloads finish, the installations have already executed.

The results are presented in the plot below, for both low-speed and high-speed internet connections.

These results were obtained by running the rustup toolchain install nightly command 10x times for each combination of variables (RUSTUP_CONCURRENT_DOWNLOADS, interleaved or not, and internet connection).
Please note that the y axis do not start on zero, and cannot be directly compared between themselves.

---

Below, I also leave a small animation of the previous and current behavior of the rustup toolchain install command to illustrate the UX changes that this PR also implies.
On the left you can see the previous version and on the right, the version with the interleaved installations.
Please note that this is just an animation and does not have the purpose of showing any kind of speedup.

Thanks for taking the time to review this PR!

[rami3l]

Modulo the previously requested changes and the two extra nits, I think this PR is quite ready. Thanks a lot, @FranciscoTGouveia!

[rbtcollins]

These results were obtained by running the rustup toolchain install nightly command 10x times for each combination of variables (RUSTUP_CONCURRENT_DOWNLOADS, interleaved or not, and internet connection).
Please note that the y axis do not start on zero, and cannot be directly compared between themselves.

As I read these results:
low speed connections :
interleaved gives 65 seconds to 59 seconds or a 10% reduction, somewhat stable for 2 or more concurrent downloads.

high speed connections:
interleaved gives 18-12 for low concurrency and 15-13 for higher concurrency, or 33% reduction for 1 or 2 concurrent downloads, and a 13% reduction for higher concurrency, with best performance at 2 concurrent downloads, and performance decreasing for successively more downloads with interleaving, but increasing for more concurrent downloads w/out interleaving.

I suspect some interaction with memory limits showing up in the unpack phase there; I suggest raising the working memory much higher, if you're on a machine that has capacity, to see if thats the case.

But also it suggests the default should probably be quite conservative, as we still need to support unpacking on Rasberry PI class machines.

[FranciscoTGouveia]

Hello everyone!

I think all review comments should be addressed by now with this and this comments being left for a future PR -- the justification can be seen in the comments.

I suspect some interaction with memory limits showing up in the unpack phase there; I suggest raising the working memory much higher, if you're on a machine that has capacity, to see if thats the case.

But also it suggests the default should probably be quite conservative, as we still need to support unpacking on Rasberry PI class machines.

First of all, thank you for your comment @rbtcollins. I have indeed reran the benchmarks with a higher memory and it didn't show any difference. For reference, it was a machine equipped with an Intel Xeon E5-2630 v2 processor and 64 GB of RAM.

Moreover, I would like to thank @djc for all the simplification work that he did, which made this PR much easier to implement. 😄

[rami3l]

LGTM modulo some questions/nits :)

[djc]

So while I did say I was fine with doing spawning/channel approach, after looking at the "remove some lifetime parameters" commit I am no longer sure if that's the best approach.

Effectively it means that whoever goes and puts in place the right architecture will basically have to undo all of those changes which IMO should not be necessary.

[djc]

(It might be useful to start split some of the commits out of this PR, since it's obviously complex/contentious -- would be useful to start landing some parts to avoid more rebasing. At least the first commit is an obvious candidate.)

[djc]

I think the correcting faulty output commits are also independent of the other tricky parts?

[FranciscoTGouveia]

I think the correcting faulty output commits are also independent of the other tricky parts?

Yes, they are. Would it be okay if I opened a PR for that now to help streamline this one?

[djc]

Yes, they are. Would it be okay if I opened a PR for that now to help streamline this one?

Definitely!