Collapse whitespace runs in message content, like HTML does

[gnprice]

As @alexmv reported in chat, the Flutter app treats adjacent spaces (e.g. https://chat.zulip.org/#narrow/stream/7-test-here/topic/Alex/near/1773775) differently than the React Native app or the web app:

Flutter	RN	Desktop

The HTML for that test message is:

$ curl -sS --netrc-file ../.netrc -G https://chat.zulip.org/api/v1/messages \
           --data-urlencode 'narrow=[{"operator":"stream", "operand":"test here"},
                                     {"operator":"topic",  "operand":"Alex"}]' \
           --data-urlencode anchor=newest --data-urlencode num_before=1 --data-urlencode num_after=0 \
           --data-urlencode apply_markdown=true \
         | jq '.messages[] | .content'
"<p>One space.</p>\n<p>Two  spaces.</p>\n<p>Many           spaces.</p>"

So what's happening is that

• in HTML, a run of multiple spaces has the same meaning (AIUI) as a single space;
• in the Flutter app, after we parse that HTML, we end up turning each of those paragraphs into (simplifying a bit) a Text widget like Text("One space."), Text("Two spaces."), Text("Many spaces.").

And I suppose it's natural that Text doesn't have that HTML behavior of collapsing multiple spaces.

---

To fix this, when we're parsing the HTML, we should match that HTML behavior. If the text in the HTML is Many spaces., we should end up putting a string "Many spaces." into our parse tree, not "Many spaces."

A key step in resolving this issue will be to work out just what HTML's space-collapsing behavior is, so that we can accurately match it. It's not only the space character aka "\x20" — in particular it includes newlines "\n" too — but I'm not sure just where the boundaries are.

There are also a few places where Zulip message HTML regularly has newline characters, and where we've adapted our behavior around those turning into visible newlines. (One is around the <br> element, and I'm not sure if there are others.) When we do this whitespace-collapsing correctly, those newlines will be equivalent to spaces; so we'll need to adapt those places accordingly in order to continue showing things as intended.

[gnprice]

One pitfall to avoid when implementing this: when the text is inside an inline code span, we'll want to keep the multiple spaces after all.

Again, the details of what that means should mimic HTML, which has the same behavior.

This comes to mind because (as @alexmv discovered) GitHub's mobile app apparently fell into this pitfall: