Progress and speed indication for downloads

[crumblingstatue]

It's useful to know approximately how much time is left until the download is finished, and at what speed we are downloading at.

The original shell script version of multirust provides this information.

[crumblingstatue]

I have 2 unsubmitted implementations of this.

1. https://github.com/crumblingstatue/multirust-rs/commit/90af77e06bdf5fd2590325d2fb3755ee4a497aa8
   This one naively implemented it using print! inside rust_install, then I realized rust_install is meant to be a library, so no user facing output should go there. I abandoned this branch.
2. https://github.com/crumblingstatue/multirust-rs/commit/b32ad1083826fde95ccb4857d66524849174446d
   Trying to build an interface for library clients to subscribe to download events, but it doesn't fit well into the current architecture, so I ended up using Rc<RefCell<T>>. I'm not yet sure if it's even possible to implement this without interior mutability with the current architecture.

Advice on how to go about this would be appreciated.

[Diggsey]

Hi, I agree this would be a useful feature! It should be fairly straightforward to implement using the existing Notification system - I'd recommend adding a new enum variant called DownloadProgress or similar, which carries the progress information. The caller can then handle notifications of this kind as they wish.

Feel free to ask here or on IRC if you have any questions!

[crumblingstatue]

One problem with using the notification system is that Notification implements Display, but download progress isn't necessarily something you want to "Display". For example, a GUI client might want to set a progress bar to some value instead of printing it with {}.

In fact, not even multirust-rs will use it, because I'm planning to use Terminal::delete_line and Terminal::carriage_return in the implementation.

But if it's okay, then I will just provide "fake" Display implementations for it to satisfy the constraints.

[Diggsey]

Thanks for implementing this!

[Diggsey]

Actually, I'll leave this open to track the missing "time remaining" feature.

[crumblingstatue]

I'm working on

[crumblingstatue]

(Stupid touch devices and their inaccuracies)
I'm working on this.
I'm going to use the time crate, since we already implicitly depend on it

[crumblingstatue]

We should try to resolve #76 before closing this issue.

[vks]

I think this can be closed. #76 is orthogonal.