Warn when haven't successfully sent notification token to server

[gnprice]

This is part of the notification troubleshooting screen, and warning banners leading to it, that we have on zulip-mobile. We should build something similar here.

[gnprice]

One particularly important situation we'll want this to cover: in the coming months we hope to implement end-to-end encryption of push notifications, zulip/zulip#6954. When we do, we expect to include a setting where realm admins can say that E2E-encrypted push notifications are the only kind of push notification available — meaning that clients from before we implement the feature won't be able to receive push notifications.

Because a large minority of users have the mobile app update only slowly (weeks or months after a new version is released), when that feature is new, enabling that setting will mean a large swath of users will stop getting push notifications. So it'd be valuable to have appropriate error-handling, and warnings to the user, out well before the feature itself, so that most of those users are at least on a version that has the error-handling and will tell them what's wrong.

In particular, this means:

• We'll need to be careful with Dedupe sending notification token to server #322: if the client successfully sent the notification token in the past, but now their realm admins have enabled the new "E2E notifications only" setting, we need the client to realize there's a problem.
• The troubleshooting UI should include any error-message text which the server sent back on a failed attempt to send the notification token. That way, the eventual implementation of E2E notifications can supply whatever error message we decide is appropriate then, and it'll be visible for users with old versions of the app from before we built that feature.

[tomlin7]

Hey @gnprice
Is the design for this ready? I see this is included in M5b milestone and was wondering if it's possible to contribute to this at this stage.

[gnprice]

Good question. There isn't a design for this in Figma, and I think we won't necessarily have one before the app launch.

So the approach I'd like to take for the design of this is:

• For what information is present and the basic shape of how it's organized, start as a model from what we have in the zulip-mobile legacy app.
• For the detailed visual appearance, use off-the-shelf Material widgets, like we do in the existing few settings screens in the app.

From there we can iterate as we see things we'd like to change, but I think that will make an effective starting point.

[gnprice]

Noting a related feature here: the legacy app includes a screen with some troubleshooting data (as a JSON blob) and a button to start composing an email to Zulip support, support@zulip.com, with that data included. That feature was pointed out by @laurynmm as part of sweeping through the Help Center for documentation that needs to change for the launch: #documentation > Flutter updates: notifications warnings and troubleshooting @ 💬

We'll want to build that feature too. (We might file a separate issue to track it.)

[chrisbobbe]

When we have a "notification troubleshooting screen" we should update the Help Center doc. We removed some stuff for the legacy app when preparing to launch the new app: zulip/zulip@31cc168