Add Progress Bar For Large Streamed Downloads

[indiv0]

Pull Request Description

This PR adds a progress bar to streamed downloads.

The build script displays a progress bar when downloading from a remote URL in non-streaming mode. It did not display a progress bar when downloading from a URL in streaming mode. Without a progress bar, large downloads in the build script make it appear as through the build script is stuck.

For example, when running with a remote backend source, the project-manager-bundle must be downloaded. This bundle is currently >1GB in size, so it takes several minutes to download. To avoid the appearance of the build script being stuck, we add a progress bar.

Screen.Recording.2023-03-28.at.09.59.22.mov

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[wdanilo]

I always wanted it so badly! That's amazing!

[indiv0]

@PabloBuchu could I get a QA on this PR please?

[PabloBuchu]

QA 🔴 Everything works fine although I couldn't make the loading bar to appear @indiv0 🤔

[indiv0]

@PabloBuchu I've fixed the issue you reported on discord RE: the progress bar clobbering logging output. Would you mind QA'ing again?

That is, it should no longer do this:

[enso-bot]

Nikita Pekin reports a new STANDUP for the provided date (2023-03-31):

Progress: Trying to resolve issues with logging not working correctly for large file downloads in build-cli. It should be finished by 2023-04-03.

[indiv0]

@mwu-tow would it be possible to get a QA on this? This touches the build process so it needs to be a cross-platform QA :)

(Pawel doesn't have a Windows or Linux machine)

[mwu-tow]

@indiv0 I will do.

[mwu-tow]

@indiv0

I did testing on Windows. Some observations:

1. Sometimes a leftover progress bar still remains in the terminal:
   
   It seems to happen when the Command is printed, likely because its debug representation contains a newline character.
2. How does this IndicatifWriter approach compares with the https://docs.rs/indicatif/0.17.3/indicatif/struct.MultiProgress.html#method.println? It was my earlier, unfinished attempt at achieving this.
3. Does this mean that we can write only to stderr without breaking progress bars?

Minor observations (feel free to leave them for later):

• Having some kind of information about what the progress bar is about would improve clarity
• Using pretty-printed size units rather than just total byte number would be more readable.

MultiProgress in indicatif - Rust

Manages multiple progress bars from different threads

[indiv0]

@mwu-tow

1. ! Looks like this was potentially fixed in Handle newline in msg and empty msg console-rs/indicatif#540, would you mind re-testing?
2. My understanding is that the IndicatifWriter approach is more general, since with the println approach there's a potential for output to overwrite the progress bar if there's multi-line output being written. With the IndicatifWriter approach, this shouldn't happen since the progress bar is removed before writing logs and re-drawn from scratch after. I may be wrong on this.
3. I'm not entirely sure, but I didn't see any issues with that in my testing.
4. I tried to add information to the progress bar, but that did break rendering, depending on how much info was provided so I decided to leave it out.
5. Pretty-printed size units would be helpful but I'm not sure how best to do that. Just manually convert the bytes to MB and print that?