[experiment] Send separate notifications when multiple accounts have new messages when app receives push notification.

[Amzd]

This also fixes notifications for classic email always bunching up with notifications of a chatmail account.

Setup of the screenshot:
The device has two accounts in the same group to simulate receiving multiple notifications at once.

Before	After

This PR also adds threadIdentifier which means iOS can decide to show each group in its own notification thread, like in the following screenshot.

This makes it harder to miss notifications for private messages when you are also in a busy group.

Tested on iOS 16 and 17, both work.

[r10s]

as discussed one-to-one, this is a nice experiment, but it is unclear if that works on all versions. it is also unclear if this is a way that apple "wants" or is more a hack. (otherwise the callback would not be needed at all). at least at some point we were not able to get a UNUserNotificationCenter to emit notifications from the NSE, cmp

so, for now, we aim for stability and do not want to risk to get new bugs in again, in the somehow working notifications.

but interesting, we should keep that in mind, and might pick that up or iterate when we interate over that part again

closing this PR and putting it to resurrection. discussion and pushing can continue, of course

[r10s]

maybe, things have changed with the "notification center entitlement" (see #2124 )

the "notification center entitlement" allows us to not add a notification. maybe that, as an undocumented side effect, that allows to schedule notifications via UNUserNotificationCenter from NSE (i am pretty sure i read that time posts saying that this is explicitly not possible, but i cannot find a link atm). but even if that's true, i would be hesitant of making use of that hack

[Amzd]

pushing can continue

hmm I pushed more commits and they don't show up in this PR, so we gotta keep that in mind when picking this up

[Amzd]

I found this which states it was not possible to queue notifications for the future in NSE in 2019. I can not reproduce this, as I can queue notifications in the future too in DC now, but it has been 6 years since then so maybe it was updated.

[r10s]

hmm I pushed more commits and they don't show up in this PR, so we gotta keep that in mind when picking this up

oh, did not knew that, we can also reopen for now (maybe it is related to the the PR not being part of deltachat-org? or os that a general thing, that closed PR are frozen and do not follow the branch any longer?)

(usually, we use "close" to make clear that we do not want to have things in just now)

[r10s]

I found this

here is another pointer: https://developer.apple.com/forums/thread/108340 , but also a bit older

[Amzd]

here is another pointer: https://developer.apple.com/forums/thread/108340 , but also a bit older

only call the Notification Extension's contentHandler once the UNUserNotificationCenter.current().add() method had fully completed.

I cannot reproduce this, even if I call the contentHandler before add it still works (on iOS 16). Might be a bug that was fixed later.

[Amzd]

Signal seems to do it this way too (just under many layers of abstraction).

They even just only send a silent notification to update the badge number and all other notifications are through UNUNC