fix(ui): upgrade tui to latest version and fix breaking changes

[imsnif]

Recently, as part of adding Windows support, we switched our TUI backend to Crossterm.
This broke the build for FreeBSD here: #188. In short, TUI was depending on an old version of Crossterm that had a bug when building for FreeBSD.
To fix this, I issued a hot fix here: #189. This upgraded TUI from 0.5 to 0.6.2, which included the FreeBSD fix, but did not have all the breaking API changes from the latest published TUI version (0.10.0).

While this did solve the problem, it did break the UI. When running locally, I was unable to see the "Total Utilization" line at the top, as well as other small glitches.

This PR solves this issue by upgrading tui to the latest version (0.10.0), accounting for all the API changes.

For ease of review, I'm going to sum the relevant parts here:

• Instead of the deprecated Text TUI widget, we're now using Span
• Instead of rendering widgets through their render function (deprecated behaviour), we're now providing them to Frame::render_widget
• In Paragraph, we can provide the Spans directly instead of wrapping them in something we can iterate over. (MUCH better IMO :) ).
• In Table, we now have to provide the widths as tui Constraint instances (not so nice for our use case, but the extra allocations are very minimal I think).
• We now need to provide the Crossterm backend with the system stdout. In our case this is not very elegant, but we should still get cross-platform functionality from the rust std::io itself, and it doesn't interfere with our tests - so I think it's fine.
• I changed some widths in the Table columns in a 2-column table-layout, because otherwise one of the titles (Remote Addresses) got cut off.
• For some reason TUI now seems to invoke hide_cursor/show_cursor before every flush. I updated these in the tests - I don't think there is any user facing effect.

@TheLostLambda - if you have time to review this (can wait a few days or even a week if you don't have the time) that would be great. If not I'll get a different pair of eyes on this.

[TheLostLambda]

Hi @imsnif ! I'm a tad busy over the next couple of days, but I should have the time later this week or early next week to give it a look!

I've also got an outstanding PR for adding a nicer interface to building Text items here. I'm not sure just yet if that will be accepted or will effect this PR much, but I'll look into that as well :)

[TheLostLambda]

Hey @imsnif ! Sorry for the delay! I think I'll take a look at this PR tomorrow! I got my changes merged into tui-rs, but I don't actually think they affect us (we don't seem to need the Text widget anymore). We could probably get away with bumping up to 0.11 though. I think that snuck in right after you put up this PR; it doesn't look like any breaking changes.

I'll give this a proper review tomorrow, but from a cursory glance, it looks quite nice :)

[TheLostLambda]

Not too much to say! Only two small comments. It looks stellar and is nice to have bandwhich on a newer TUI version!

[TheLostLambda]

We should be able to change this to 0.12 without breaking anything. I've given it a test on my machine and no breaking API changes have been made since 0.10 I don't think.

[TheLostLambda]

Sticking strings together in Rust always gives me a bit of grief, but I think this also works here:

[pause_content, tab_text, dns_content].concat(),

To me it seems a tiny bit cleaner and is, apparently, about 3x faster because it can pre-compute the size of the final string I think. We are talking nanoseconds though, so it really doesn't matter and is a matter of style I think :)

[imsnif]

Aha, good to know - thanks! I made the change.

[imsnif]

Btw, @TheLostLambda - I sent you an email on a different subject. Mentioning it here because I remember there were some spam-filtering issues between us in the past. :)