Follow up on https://github.com/stepchowfun/docuum/pull/90

[stepchowfun]

This is a follow-up to #90. Instead of providing feedback in that PR, I've decided to accept it as-is and apply my suggestions here. Some of the changes here are actually worse than what was in #90 (e.g., due to copying small structs around rather than worrying about lifetimes), but they are easier for me to understand and maintain. I've also increased the type safety and asymptotic performance (the previous complexity was quadratic in the worst case due to the fix_node_timestamps function, but I've changed the corresponding logic here to be linear-time), although these changes are unlikely to be noticeable in practice. Sadly I have not written automated tests for the revised logic—my manual testing will have to do for now.

Status: Ready

Fixes: N/A

[stepchowfun]

Hm, during my testing for this change, I noticed that for some reason Docuum since version 0.12.0 (switching to bollard) doesn't seem to be receiving events from Docker. Sadly I might have to revert all changes since then if this is a real issue and not just my imagination. I'm not sure how this wasn't detected sooner.

For now, though, I'll merge this PR since the new logic appears to work well (minus the event streaming).

[mdonoughe]

Are you seeing this event issue on Windows only? I got some weird behavior with WSL once when investigating something somebody had reported. Maybe there is a problem with the WSL pipe/socket bridging?

Theoretically, if we delete the packages in the right order then we don't need the deletion reason check that depends on Bollard. Alternatively, Bollard could be used only in places it matters (deleting, possibly one of the queries), and go back to the CLI for events.

[stepchowfun]

I'm on macOS, not sure about Windows. I just filed a Bollard bug here: fussybeaver/bollard#113

If we switch back to using the Docker CLI, I think I'd prefer to just use the CLI for everything and not do a hybrid solution. It doesn't seem too bad to go back to checking disk usage after every image deletion attempt, since the better deletion ordering results in far fewer deletion failures.