ios: Keyboard can briefly reappear after "Share" is tapped and before the share sheet appears

[chrisbobbe]

(This is a milder version of #24, I think; the main symptom of #24 seems to have been fixed in an iOS update.)

If the topic or content input in the compose box was focused when you long-pressed a message, then this sequence is reproducible:

1. The message action sheet opens in response to your long-press
2. At the same time, the keyboard goes away
3. You tap "Share", and the message action sheet closes
4. The keyboard briefly reappears and disappears
5. The share sheet appears

It would be good to eliminate step 4.

The keyboard's entrance and exit are unnecessary and unexpected changes of context, so I'm labeling this as an accessibility issue (a-a11y). (The cognitive burden is particularly relevant for our users who are easily distracted, for example. It's also possible that some annoyance or confusion is created for screen-reader users; I haven't tested so I'm not sure.)

Here is a recording of the behavior, helpfully provided by @Khader-1 on issue #24:

[chrisbobbe]

The keyboard's entrance happens because the message action sheet route is popped. The message-list route under it becomes the active route. That route has a focused text input (in the compose box), which makes the keyboard open.

@Khader-1 mentions one possible solution:

• Keep the message action sheet open until the share-sheet action completes successfully.

That might be the cleanest thing to do, actually. But we do have a comment in the current code, which I wrote, in the place where we dismiss the message action sheet before opening the share sheet:

    // Close the message action sheet; we're about to show the share
    // sheet. (We could do this after the sharing Future settles
    // with [ShareResultStatus.success], but on iOS I get impatient with
    // how slowly our action sheet dismisses in that case.)

The words "how slowly our action sheet dismisses" refer to the exit animation of the message action sheet, which would start after the share-sheet action succeeded. I wouldn't put too much weight on my report of "impatience" there; I didn't spend much time in manual testing, and I'm open to changing my mind about how important it is to be quick there. 🙂

There's an alternative we could try, though, described by Greg at https://github.com/zulip/zulip-flutter/issues/24#issuecomment-1464631585 :

instead of popping the action-sheet route, we replace it with a new route that's the "share from Zulip" route. That route would do very little except (a) summon the system sharing modal, and (b) serve as a placeholder on the navigation stack, so that any state from the route before the action sheet doesn't try to restore itself until the sharing interaction is complete.

If that route replacement were instantaneous (i.e., the message-list route never activated between pressing "Share" and the appearance of the new route), then the keyboard should not reappear, and also the share-sheet action shouldn't need to be followed by the slow exit of the message action sheet.