Await send request; handle failure

[gnprice]

If you're using the app, then step into an elevator (or otherwise lose your network connection), and hit send on a message, the current experience is pretty bad: the message just vanishes, there's no error message, and you don't even get back the text you wrote so you can try again.

The UX we'd ultimately like to have here is local echo, with an "outbox" system that can retry the send when you're back on the network:

• Local echo when sending messages #576
• Implement outbox system #133

But those are complex to get right, and I think we won't get to them in the next few months. There's a much simpler thing we can do that would greatly mitigate this, so we should do the simpler thing first.

Specifically, when you hit the send button:

• We'll put the compose box and send button into a disabled, "working on it" state — for example the text inputs might be grayed out, and the send button showing a spinner instead of the "send" icon.
• In that state, we'll let you select the text from the input box in order to copy it, in case you decide it's taking too long and want to give up.
• We'll await the result of the send request. If it succeeds, the send is done and we can proceed just like the send button does now: clear the input and take it back to a ready state. If it fails, we'll show an error message and make the input ready again, but still holding the text the user entered.

(To keep this simple to implement, we'll only be waiting for the send request to complete — not for the message event, which is what causes the message to appear full-fledged in the message list. This means that the message might appear in the list before or after the compose area goes back to ready. I'm hopeful that in practice this won't often be bothersome, and will be better than the status quo. If we find we need to wait for the message event in order for the interaction to feel right, then that gets a lot closer to a full version of #133, and we'll re-evaluate whether there's still a simple version that makes sense.)

@terpimost will be preparing a more concrete design. Until that's ready, this issue isn't ready for implementation.

Thanks also to @terpimost for the feedback pointing out the need for this, in particular the elevator story :-)

[gnprice]

I've filed the first steps of this feature, which will already be useful in themselves, as a separate issue:

• On failed message send, show error dialog #815

[terpimost]

Does this reflect the logic?

https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=4031-13405&t=hE9wEtLE59jG5rUn-1

[gnprice]

That looks good, thanks!

I think we'll need to allow a much longer timeout than 5 seconds — sometimes people are on slow network connections (or flaky ones such that the network needs to retry the packets), and sometimes their server is slow. Something like 30 seconds is probably long enough.

Because that'll be a while and the user may want to give up and move on sooner, there's this item we had above:

In that state, we'll let you select the text from the input box in order to copy it, in case you decide it's taking too long and want to give up.

[PIG208]

The new design part of this is probably blocked by #915. I think we should move this to the "Launch" milestone as well.