Refactor the DownloadTracker in favor of indicatif

[FranciscoTGouveia]

Closes #1835.

This PR refactors the current manual DownloadTracker progress reporting, replacing it with an indicatif-based implementation, as previously discussed in #1835 and #3828.

This change is a first step toward enabling concurrent component downloads, as the MultiProgress construct of indicatif will very helpful to concurrently report progress.

In terms of performance, benchmarks using hyperfine showed no noticeable difference.
Benchmarks were run 20 times (with 2 warmup runs) over a 50 Mbps connection, each downloading an entire toolchain.

Thanks to @0xPoe and his previous PR, which served as the basis for this change.

Prior art: #2610, #2828, #3349.

[rami3l]

For the reference, the current style is like so on my machine:

... and the original goes like:

info: downloading component 'rust-docs'
 20.2 MiB /  20.2 MiB (100 %)  20.1 MiB/s in  1s  

[rami3l]

@FranciscoTGouveia I am thinking, the percentage has been replaced by the bar, but the speed meter might still be worth it (and I don't think the timer is that important)?

info: downloading component 'rust-docs'
[███████████████████████████████████████░] 20.09 MiB/20.22 MiB (20.1 MiB/s, ETA: 0s) 

Also, I actually prefer the legacy progress bar style, something closer to pacman or apt:

info: downloading component 'rust-docs'
[####################################    ] 20.09 MiB/20.22 MiB (20.1 MiB/s, ETA: 0s)

@djc @ChrisDenton What would you like (and don't like) to see in this interface that you might see every now and then?

[rami3l]

Thanks for this PR and your prompt update afterwards!

It should be noted though that given the current commit guidelines, any back-and-forth in a single PR should be squashed back to the original commit.

Also, I'd like to wait for my teammates to see if the current style goes for them:

[ChrisDenton]

I'll admit to not having any strong opinions here but the current style looks fine to me. The ETA can be useful on slower connections so it's clear if you should go and do something else for 20 minutes. Also when the CDN is having issues. Admittedly this can be discerned by looking at the download rate if you're thinking about it.

[rami3l]

Thanks again for the work, your patch works pretty well on my machine!

LGTM modulo some minor suggestions :)

[djc]

Also, I actually prefer the legacy progress bar style, something closer to pacman or apt:

Can you explain why?

[djc]

Why do this?

[rami3l]

@djc This is to be coherent with the old rustup logic where if a progress is considered to have finished instantly, the corresponding progress bar will remain invisible all along.

Also, the .clone() action is cheap because ProgressBar has referential semantics.

[rami3l]

Also, I actually prefer the legacy progress bar style, something closer to pacman or apt:

Can you explain why?

Being a universal tool, we would expect rustup UI to work correctly even if our host doesn't come with proper support for Unicode (this doesn't mean non-ASCII chars are not displayed; but it could mean that they can be shown in a surprising way to be no longer suitable for UI use).

Cargo, for example, has to detect this in case it needs to provide a fallback (thanks, @weihanglo!). The same is true for Python's rich and more. IMHO this is not providing much additional value to our simplification plan, so going with a more traditional solution means we don't have to consider such complexities.

As for the actual character set being used, "## " is my personal preference, but "=> " is another option that I have considered so the progress bar could look more like cargo. UV seems to be using "-- " to be closer to rich and friends.