Systematically survey message content for unimplemented features

[gnprice]

Our parsing of Zulip message content HTML is designed to be precise about what it expects, and explicit about anything it doesn't understand. This means that when we encounter some content that does something we don't have support for, our code generally knows that, rather than silently plow ahead with a wrong interpretation.

This is helpful because, among other things, it means that if we take a corpus of Zulip message content, we can run our parser on it to learn about constructs that exist in the wild that we haven't yet implemented. (This includes constructs that a current Zulip server will generate, and constructs that older servers would generate and consequently still exist in old messages.)

So we should do that, as an iterative process:

• Run on some set of messages; find things that are unimplemented; file issues; fix them, or at least those that are most common, until the number of unsupported messages is small.
• Then run on a larger set of messages, or one with more very old messages, to find more unimplemented things.
• Repeat until it's difficult to find a message with something we don't know about, and we're comfortable with whatever set of known unimplemented features remain.

Some specific likely steps in that process:

• Write a script that can fetch a bunch of messages in a loop, feed them through parseContent, and report any UnimplementedNode results (as well as any crashes, which should be fixed immediately).
• Run that script on some recent public messages (i.e., messages to public streams) on chat.zulip.org.
• Run it on all public messages on chat.zulip.org.
• Run it on all public messages in realms that publicly list themselves as open communities. For example, have the script sign up a test user in each realm and log in as that test user.

[gnprice]

We'll also want to keep these scripts in reusable form. It'll be useful to rerun them periodically, both as we make changes to the parser and to validate that there aren't new patterns we haven't implemented and are unaware of.

In particular when there's an invariant we believe applies and want to validate that empirically, we can add asserts for that invariant to the parser and then rerun the survey script, and see if it finds failures.

(We'll basically always want to run the script with assertions enabled, since the point of it is to find situations we didn't expect.)

[gnprice]

(Separately, when we run into an unimplemented feature in a message we're trying to show in the message list, our current UI is pretty loudly explicit about that. That's helpful for development but we'll naturally want to handle it differently for normal use beyond the beta: #194.)