When we use a fetch to "subscribe" to new data, cancel it if in progress at REGISTER_COMPLETE time.

[chrisbobbe]

Often, we initialize a model with data from REGISTER_COMPLETE, then just listen for events and use them to update the model.

Sometimes, though, we "initialize" data in a model with the result of a non-initial fetch (like GET /messages), then we listen for events that affect the fetched data. The most famous example of this pattern is fetching messages; see https://github.com/zulip/zulip-mobile/blob/main/docs/architecture/realtime.md and https://zulip.readthedocs.io/en/latest/subsystems/events-system.html .

When we're using this pattern, we should cancel the fetch synchronously with dispatching the REGISTER_COMPLETE action, so that our reducers don't process its payload after we get a new event queue, thus clobbering some state that we intentionally reset or replaced on REGISTER_COMPLETE.

We should also cancel these fetches when the active, logged-in account changes; that's #5009.

When canceling a fetch, we shouldn't forget to update any metadata that tracks its state, like state.fetching.

I believe these are the fetches we use this pattern with:

• api.getMessages
• api.getTopics
• api.reportPresence (to subscribe to users that didn't exist at REGISTER_COMPLETE time)
• (There may be more.)

Issues #4170 and #4659 cover parts of how we might do this. Marking as blocked on those.

[chrisbobbe]

See #5609 for a proposal to cancel such fetches with DEAD_QUEUE instead of REGISTER_COMPLETE, and #5609 (comment) for why we ended up choosing the latter instead.