Add CLI progress bars

[fischeti]

CLI Progress bars

Adds progress bars to bender actions that require longer network access. A taste is shown below*

*some style changes have been done since this recording.

Implementation

The progress bars are rendered with the crate indicatif, that allows rendering of multiple progress bars at once. The state of the progress bars is extracted from the stderr output of the spawned git commands i.e. a separate task is spawned alongside git tasks to parse git output lines and update the progress bar state. I initially thought about adopting the git2 crate, which would have built in progress callbacks. However, this would have been a larger change and also poses some challenges since those git tasks are not asynchronous and also credential handling would be more complicated, which is why I opted for stderr parsing in the end.

Related Changes

Apart from the implementation of the progress bars, some additional changes were necessary:

error macros

Previously, all messages were simply printed to stdout/stderr with println!/eprintln! without any specific order. Rendering the progress bars together with warning/error messaged caused unwanted artifacts. The reason is that the progress bar requires exclusive access over stdout/stderr, since it needs to clear lines again. If warning/error messages are sent in between, it might clear the warning/error message instead of the actual progress bar which is left behind as an artifact. For that matter, the MultiProgress instance can be suspended, which essentially means clearing all progress bars, writing the desired custom message to stdout/stderr and then redraw all the progress bars. This means the previous warnln!, errorln! etc., macros are now passed through the MultiProgress.suspend() function.

git spawns

• Where appropriate the git spawn functions now accept a Option<ProgressHandler> argument. If None is passed, the behaviour is as before, whereas Some(pb) will add a new progress bar.
• The git submodule update commands are only performed if a dependency contains a .gitmodules. Otherwise, too many no-op progress messages are spawned.

TODOs

• Check more bender commands. I focused mostly on checkout, but others use the same underlying functions so there should not be an issue in theory.
• Check output in log files (e.g. CI). In theory, this should work outside of the box.
• Revert git throttling changes

[micprog]

Very nice feature, providing some insight into what bender is doing at the moment! Some comments below.

[fischeti]

I should have addressed all the comments now. Additionally, I added the following:

• 0949dda: All colored messages (e.g. stages, warnings etc.,) will now only be collored in environments that allow colors i.e. if NO_COLOR is not set in the environment. For instance bender command 2> command.log will not contain any ANSI codes anymore.
• 2f884e5: I aligned the formatting of update command during manual version resolving to the ones introduced with progress bars and the diagnostics (This is also why the CLI regression test fails at the moment, since I removed the backticks when rendering paths.)
• bd380f4: I changed to style of versions (cyan now) to differentiate it from the style of packages (white bold). I am not fully satisfied with the look tbh, so we can also revert this. Or if you have a better idea let me know.
• bb71e62: Fixes an issue where stageln messages interfered with the progress bars. This was very rare but I noticed it a few times when symlinks were created for dependencies, while cloning was in progress. Now stageln always suspends the progress bars to fix this issue.

[micprog]

LGTM, thanks! 👍

[micprog]

CI failures look to be slight formatting adjustments in the parents command, which are OK to merge IMO.