Handle event-vs-fetch races soundly

[gnprice]

For almost every kind of data we get from the Zulip server, we use the Zulip event system to maintain an up-to-date snapshot where all of the data is internally consistent with all the rest. (For background on this, see https://github.com/zulip/zulip-mobile/blob/main/docs/architecture/realtime.md and https://zulip.readthedocs.io/en/latest/subsystems/events-system.html .)

The major exception is the content of Message objects: each message's contents, emoji reactions, topic, and so on. Because the message history is so voluminous, we don't fetch a snapshot of all of it up front; rather, we fetch the history for a given message-list view (a conversation, a stream, a list of search results, etc.) independently of the event system.

But some of the information about a message can change over time: the message is edited, is moved, gains or loses reactions. That information comes in events.

Because the message fetch happens outside the event system, it doesn't benefit from the sequential ordering that the event system gives us. As a result, there are races if the server gets a change to a message concurrently with a request from us fetching the message:

• We might fetch a message with data that reflects some change having already happened, and then later get the event that makes that change.
• We might get an event to update a message, and then later get the result of a message fetch with data from before that update.

Some chat discussion here, following a user report of duplicate emoji reactions, which is a symptom these races definitely can cause, at least in principle.

This is one of many small unsoundnesses in our handling of server data that we currently paper over by regularly re-fetching the server data from scratch. Like #3408, we'll need to resolve this one before we can go fully down the path of #3916, i.e. of relying on the event system to keep data much longer without re-fetching from scratch.