Remove "send-in-progress" outbox placeholder when the message appears in a fetch

[chrisbobbe]

A user reports:

#mobile > Mobile client on iOS - poor performance @ 💬

On a weak connection the mobile app (Flutter, iOS) leaves a sent message showing a "sending" state for a long time — sometimes appearing as a second, un-acknowledged copy under the delivered one — so it reads as stuck or duplicated.

This can happen when the event stream has gotten "stuck" or delayed (see e.g. #1884, #514 for ways this can happen) but send-message request and message fetches are succeeding. In particular, if events aren't coming in, you can send a message → the request succeeds but no event yet → you leave and re-enter the message list, triggering a fetch → the sent message arrives in the fetch, but the outbox-placeholder copy is still present.

I think this should be straightforward to fix: the send-message success response contains the message ID, which we can record on the OutboxMessage object. Then we can drop the outbox message in reconcileMessages.

[chrisbobbe]

I think there are actually three things to do here, for a decent experience when the event stream is stuck:

• The common case is that the send-message request completes first, and the fetch arrives later, carrying the message. This is covered by the reconcileMessage proposal above. -> Done in msglist: Drop outbox message when its message arrives in a fetch #2413.
• But the reverse can happen too: the fetch comes in first, carrying the message, but we don't hear the send-message response until later. We should be able to handle this case by checking MessageStore in _outboxSendMessage before deciding to add the OutboxMessage / placeholder.
• Removing an outbox placeholder removes it from all message lists. If the event stream is stuck but the message has arrived in a fetch (through either of the above paths), then the message will be shown in the message list that performed the fetch, but not in any other message lists until they do their own fetch, and the outbox placeholder will be absent. So from those other message lists, until the event comes in, it'll look like the message was dropped. One proposal to address this: for any other message lists where the message belongs, if they think they're caught up to the newest messages (haveNewest is true) but they don't have this message, just correct that impression (set haveNewest to false) and prompt them to fetch-newer.

[chrisbobbe]

Oops: looks like the commit message of 80cbe7c triggered auto-closing of this issue because it said

Partly fixes #2397.

(Apparently GitHub still has the behavior of recognizing and acting on fixes #2397 even when preceded by a qualifier like "partly".)

In future I'll try to remember to say "Fixes part of #2397." IIRC this phrasing avoids triggering the auto-close, since there are words between "Fixes" and the issue number. 🤦‍♂️