Boomerang tests for Zui's ZSON-like output

[philrz]

As this issue is being filed, Zui is at commit e7febec.

Some recent findings like what's described in #2875, #2876, and brimdata/super#4851 have led me to contemplate if these are part of a wider area of exposure. I've talked it over with @nwt and we reached some consensus on a way we might improve on it when we can justify the effort.

To frame the proposal, I'll start by taking a step back and citing some facts and assumptions.

Facts

1. Per https://zui.brimdata.io, Zui is known as the "Zed User Interface".
2. Per the ZSON format doc, ZSON is considered the "human-readable, text-based serialization format" of Zed.
3. Humans use Zui to read their Zed data.
4. As the Zed CLI tools and Zui app are both ways of working with the same underlying Zed data, we seek to provide a seamless experience for users when switching between the two.

This leads me to an assumption that I don't think has been written down anywhere but I've taken for granted:

In its role as the Zed User Interface, I expect the Zed values rendered by Zui will align with the human-readable ZSON format.

However, in polling @jameskerr, he had a slightly different take:

You can think of the Zui Inspector as "Yet another format for Zed data". With all the expand, collapse, truncate logic.

This is a fair point, as there's indeed some devil in the details here. For instance, consider this screenshot:

We can see that the app has added the array index prefixes (0:, 1:, etc.) to make it easier to spot individual elements.

Also, if we collapse the array, we can see that the app renders it in a summary format with portions truncated to hint where the user might want to expand it.

I can't say for sure if these are the only places where Zui's output diverges from strict ZSON in the interest of helpful presentation. However, if there's agreement on my 4th Fact above, I would hope that once a user knows to ignore things like the leading array indexes and does a cut & paste or manual retype of a presented value from Zui's ZSON-like format into a Zed CLI context that expects ZSON input, it would "just work". The experiences of #2875, #2876, and brimdata/super#4851 indicate this has sometimes not been the case, and I'm anxious that more examples of this are lurking out there and will only be found in this individual "whack-a-mole" fashion.

When talking with @nwt, we agreed that something like the "boomerang tests" we perform within the Zed repo might be helpful here. We could write some test automation that that scrapes expanded ZSON-like Zui output, drops the known presentation enhancements (e.g., the leading 0: on array elements), and then feeds the resulting text back into Zed's ZSON reader. Like we do for the boomerang tests, the corpus of data used as input could be taken from the Zed ztests, since these are already known to cover a diverse set of possible Zed inputs.