Independent filetree buffer + partial tree rendering

[wagoodman]

This was a dozy. Essentially pprof was indicating that too much time was spend writing large strings to the gocui view buffer. This makes sense: when any event occurs (e.g. cursor up, down, collapse, etc) we render a filetree string and write the entire tree to the buffer.

One considered fix was to cache all written lines so when a simple action occurs (such as a cursor move) we are only updating that those two lines (instead of writing the entire tree). Unfortunately, gocui doesn't have a buffer seek or line update methods to use, so that approach was ditched.

Instead filetree.String was adapted into filetree.StringBetween to only generate a string of nodes between two DFS-ordered indexes in this tree. This implied that a non-recursive approach to generating a tree, which makes the code more verbose but easier to reason about what will happen next.

A side effect of this was that the gocui buffer would not be utilized. That is, if I write a string to the buffer that is larger than the screen dimensions, then a scrolling mechanism is provided for a user to view more of the string buffer. However, now that we are essentially only rendering a strings large enough to fit on the screen (instead of the whole tree) it no longer made sense to use gocui's scrolling capabilities (i.e. SetOrigin).

So... this PR implements a new filetree buffer that:

• generates a portion of a tree string (only what can be seen on the screen given the terminal dimensions)
• takes over scrolling from gocui (keeps track of an indepentent view index)

What does this buy us? Now when viewing a very large tree the view is much more performant (before this, it was quite laggy)

[willmurphyscode]

Did you mean to uncomment this print statement?

[wagoodman]

actually, I never meant to comment it out to begin with :)

[willmurphyscode]

I don't understand why you never process the root. Does this mean that the line / in the file system never shoes up in the output?

[wagoodman]

Indeed, this is so the root dir never shows up in the filetree and we also don't have any information on it. The tar you get from the docker save command has the contents of what in the images root dir, but no info on / itself. I couldn't see a reason to include it in the tree other than to hide all files... so I left it out.

However, from a data structure point of view keeping a single root node simplifies how you traverse the tree (instead of having multiple root nodes you have one, and the children are the "real" start to the tree).

Downside is preventing weird one-off bugs :/

[willmurphyscode]

I like this solution. I just had a couple questions. Approved.