Facilitate progress bars

[CodyCBakerPhD]

OK, to be fair, this one is definitely not for the Pennsieve team, but for our own tools...

Progress bars are great all around. For long operations, including download/upload of large files/datasets, they can provide a user with tangible proof that 'something is happening'. They can also estimate (with variable reliability) how long it will take until the process completes.

A typical library for progress bars in Python is the very popular TQDM. I hope we all know how to use that, but it not just let me know and I'll be happy to give pointers.

The downside for a cloud setup however is that all the stdout/stderr piping is inside an ephemeral unit and can only be seen through runtime logs and the like.

We previously extended various packages in our ecosystem (HDMF/NeuroConv, not DANDI yet sadly... would be good first step) to accept custom TQDM wrapper classes for the NWB GUIDE, which then defined a specific callback forwarding class according to a Publication-Subscriber model and passed it to those downstream libraries. This resulted in a TypeScript-based frontend being able to render real-time updates from a Python backend.

What we want is pretty darn similar here, but a tad more nuanced because backend is remote rather than local, and would likely forward to some dedicated web app. Garrett and I had a prototype of this at some point, but I doubt it is alive any more. Might need to revive that.

Not assigning this right at the moment, but raising awareness for @rhingo so that in the back of your mind, if you can note when running a process that you wish you could know when it might finish, that is a case where this would be useful.

[CodyCBakerPhD]

From the logs of the sleap-nn MVP by @rhingo, the process naturally has TQDM built-in somewhere and results in this ugliness:

Also spamming/filling log contents. If reroute to the publisher is not possible, should at least suppress output where we can.