factor out notification token handling

[r10s]

this PR moves the handling of the notification token to DcAccounts and DcContext objects using the new core API that supports real push notifications (correct core PR needs to be checked out at deltachat-ios/libraries/deltachat-core-rust manually to make this PR work)

Overview of related PRs:

• notifiers PR: feat: add /notify endpoint notifiers#17 (adding endpoint to receive notifications from chatmail server)
• chatmail PR: Enable push_notification plugin chatmail/server#201 (adding metadata server to register device tokens for notifications and sending them to notifiers)
• core PR: feat: dc_accounts_set_push_device_token API deltachat-core-rust#5286 (adding APIs to set tokens and register them with chatmail servers or fallback heartbeat notifications)
• this iOS PR: factor out notification token handling #2080 (using new core APIs)

EDIT: apart from the expected issues wrt "mute chat" and "mute all" the PRs play well together and things are working nicely (idea for "mute all" is to drop that switch and just open system notifications setting where you can "mute all" as well. or, if per-account-mute is needed, a revoke api. for "mute chat", maybe this is doable by a notification service exetension as well; i started a branch with that. that could also be used for "mute all". we'll see :) both, however should not block merging this pr)

there are two new API that will be replaced by the following core implementation soon:
- dc_accounts_set_notify_token(token) - passes the token received from apple to the core. core will forward it to supported (chatmail) server or, as a fallback, use it for heartbeat. as we have only one token for all accounts, core will do that for all accounts. the method may be called on every app start as the tokens may be short-living. the function may take a while (we should decide if UI needs to call it in a thread or core does that) there is no need for a return value, UI will check the state using the following method.
- dc_context_get_notify_state(context) - returns NOT_CONNECTED (0), HEARTBEAT (1) or PUSH (2) - this is a per-context method as some accounts may use chatmail while others not. the method is used by the UI mainly to show the state to the user
the PR adapts flow and connectivity view already to these new calls, however, still uses a "dummy" UI implementation. i also did this PR to make myself clear what is actually and really needed for UI :) (@hpk42 and me are first thinking that we can just use a set_config(), however, this does not work nicely as the token is same for all accounts)
@link2xt @zeitschlag if this roughly makes sense to you, i suggest to merge this PR already in, we can then focus on the core EDIT: we decided to go for changing core directly

[link2xt]

Core part started here: deltachat/deltachat-core-rust#5286

[zeitschlag]

I'd suggest to do nothing for now and wait until Core implemented this. Then we can remove lots of code and just call the core.

[r10s]

I'd suggest to do nothing for now and wait until Core implemented this. Then we can remove lots of code and just call the core.

makes sense as well, esp. as the core part is already in the making :)

[link2xt]

What do we need dc_context_get_notify_state for? It makes sense to know whether the server supports push (i.e. whether it is a recent chatmail or not), but do we really need to know for an account (single context) whether we have registered for heartbeat or not?

I am still not sure how heartbeat registration should happen. On the one hand it is not per-context because if user has 2 accounts we don't need to register twice with the same device token. On the other hand if user has a single account configured with SOCKS5 to use Tor, we definitely don't want to register by connecting directly to notification server bypassing Tor. How should we register for heartbeats if we have two accounts, one configured with SOCKS5 and the other not?

[r10s]

What do we need dc_context_get_notify_state for? It makes sense to know whether the server supports push (i.e. whether it is a recent chatmail or not), but do we really need to know for an account (single context) whether we have registered for heartbeat or not?

indeed my idea was to know for an account (single context) to know if heartbeat was registered or not and show that to the user (as "Not Connected" - as it may also mean the token is pending or the device is really not connected or just about to connect)

i think, this is useful for debugging.

I am still not sure how heartbeat registration should happen. On the one hand it is not per-context because if user has 2 accounts we don't need to register twice with the same device token.

yes. i'd loop over the account list and register for "real PUSH" where possible. only if there are accounts left, register one time for heartbeat.

so, we have the following pseudeo code (EDIT: refined):

pub struct Accounts {
    registered_for_heartbeat: bool;
    ...
}

pub struct Context {
    registered_for_real_push: bool;
    ...
}

fn set_notify_token(accounts: &Accounts, token: &str) {
    needs_heartbeat: bool = false;
    for context in accounts {
        if context.register_for_push_if_possible(token) {
            context.registered_for_real_push = true
        } else {
            needs_heartbeat = true
        }
    }
    if needs_heartbeat {
        if accounts.register_for_heartbeat(token) {
            accounts.registered_for_heartbeat = true;
        }
    }
}

fn get_notify_state(context: &Context) {
    if context.registered_for_real_push {
        return DC_NOTIFY_REAL_PUSH;
    }
    return accounts.registered_for_heartbeat ? DC_NOTIFY_HEARTBEAT : DC_NOTIFY_NOT_CONNECTED;
}

On the other hand if user has a single account configured with SOCKS5 to use Tor, we definitely don't want to register by connecting directly to notification server bypassing Tor. How should we register for heartbeats if we have two accounts, one configured with SOCKS5 and the other not?

i think, SOCKS5 and tor is nothing we should worry about currently. there are not even the corresponding options and on apple devices, not sure, how useful in general this is.

but to the question: if somehow any account is using SOCKS5 or Tor, i'd skip the whole registeration for all contexts

[link2xt]

if somehow any account is using SOCKS5 or Tor, i'd skip the whole registeration for all contexts

Makes sense, sending device id over Tor is dangerous, better not register for push at all in this case.

[Simon-Laux]

dc_accounts_set_notify_token(token)

should also include the url or just take "url+token" (edit: makes sense to have them separate, if we want to keep transmitting the token in the body of the request) so we can both easily support sandbox and production tokens

[Simon-Laux]

I think you can register the heartbeat even when using tor for single accounts, tor on iOS likely means a vpn for everything anyways?
also heatbeat is not that sensitive of an information anyway, you would just learn that a user uses deltachat when monitoring the non-tor traffic.

[link2xt]

the function may take a while (we should decide if UI needs to call it in a thread or core does that)

set_notify_token should be immediate, it will just store the token in memory. We are only going to actually register only once we connect to some IMAP server and get its capabilities, so we know the server does not support actual push notifications.

[link2xt]

dc_accounts_set_notify_token(token)

should also include the url or just take "url+token" (edit: makes sense to have them separate, if we want to keep transmitting the token in the body of the request) so we can both easily support sandbox and production tokens

Even notifiers server does not deal with the URL directly, they are hidden inside a2 crate: https://docs.rs/a2/0.8.0/a2/client/enum.Endpoint.html

Hostname of notifications.delta.chat I am going to hardcode into the core and chatmail service because otherwise we will need a mechanism similar to PushVerification in JMAP to make sure nobody can subscribe arbitrary URLs to our notifications. We can add API to set URL alternative to notifications.delta.chat later if needed.

From the core point of view device token is completely opaque, core will only forward the token to notifications.delta.chat or chatmail server via IMAP METADATA and never look into the token itself. I don't know when api.sandbox.push.apple.com is needed, but if we want to support it for developer builds I suggest that we remove --sandbox flag from notifiers and instead connect to both Apple endpoints from a single process. notifiers then can look at the token and forward notifications to one server or another based on the token itself, e.g. we can add sandbox: prefix to tokens that are registered with the sandbox server.

[r10s]

i adapted the PR so that it uses deltachat/deltachat-core-rust#5286 directly now

[Simon-Laux]

works nicely

[r10s]

k, merging that in.

"in-app muting chats" is not working for c20/nine.testrun.org when notifications are enabled in the system, however, the advantage of having reliable push notifications makes that a minor - and a fix for muting & co is already on its way with #2105 (but needs some more time so that it should not block ongoing release efforts)