Dedupe sending notification token to server

[gnprice]

In my initial implementation of #122, I plan to have the app just tell the server its notification token again and again on each launch.

As a follow-up, we should have it instead remember when it's already successfully told the server its token, and then not tell it again. We do this in zulip-mobile.

Actually, there's a refinement to make. Google's docs recommend that the client should repeat itself to the server, but only after a month:
https://firebase.google.com/docs/cloud-messaging/manage-tokens#ensuring-registration-token-freshness
That then allows the server to conclude when a token hasn't been re-registered in, say, two months, that it's stale — that the client has gone away — and Google recommends that the server stop sending notifications to it in that case. (I don't recall seeing that recommendation the last time I studied these docs, several years ago. Not sure if Apple also recommends something similar these days.)

[gnprice]

One wrinkle in this plan: in the future, with end-to-end encryption of push notifications, we expect it to be possible for a client to have working push notifications, but then a realm admin changes a setting on the server, and now the client no longer gets push notifications (even though they remain logged in and able to use Zulip through opening the app as usual). Details here:
#323 (comment)

That specific scenario will only apply when the client app is a version from before the implementation of end-to-end encrypted notifications. I'm not sure if we'll have other scenarios of this kind in the future.

In any case this probably means that at least before we implement E2EE notifications, we should dedupe these requests only when the last one was within a short window, like the past day. That way (once we have #323) the user will still learn reasonably quickly if their push notifications have stopped working because the realm admins started requiring E2EE and they need to update the app.