NotificationService get_notification_item implementation

[Velin92]

The NotificationService stub that I made in this PR is not able yet to fetch the content of a TimelineItemEvent since the sliding sync is not capable of accessing these elements yet.
However once the sliding sync (or another way around it is found) would allow for fetching such content given the room_id and the event_id we should implement a way to create the notification item and send it back to the client using it.

[manuroe]

We want to use /sync to retrieve the matrix event associated to a push. It is very similar to what we have in current element mobile apps. Except current apps use sync v2 and a lot of data. We are going to use sliding sync.

The behavior in Element-iOS and its SDK is:

• the app has a queue of incoming pushes to resolve. We resolve pushes one by one to keep the displayed notifications order right. This queue could be managed the SDK
• the SDK first looks if we already have the message in cache. If yes, we return it. This happens when there is a lot of incoming messages in a room. /sync v2 is slow and it can return data for multiple pushes. We probably need to consider it with sliding sync too for bad network condition.
• the SDK makes a /sync request. The response is managed as when the app is running:
  • all response data (to_device, state, timeline, etc events) is parsed and stored in cache
  • push rules are executed against each received timeline events
  • this request is retried 3 times as any request
• if a push has been raised for the incoming push event_id
  • SDK returns the event and the push rule
  • app checks the read marker if the even has been already read. It could be done earlier in the SDK
  • app fetches more data from the room state: names and avatars of the room and the user. The SDK should provide them directly
• App moves to the next push in the queue and restart the loop described here

Notes:

• Element Android has a similar behavior. One noticeable difference is that EA displays notifications for every message encountered in the /sync response that matches a push rule. It does not one by one like iOS
• iOS does crazy things to cache the response data a the multi-process environment
• Android stored data in its DB

To consider:

• multi-process and low RAM level on iOS
• iOS expects 1 notification per push
• iOS has a 30 seconds timeout to return a notification
• caching. Tapping on a notification is a main entrance of a messaging app. The timeline must instantly displays
• later: push rules updates. Current Element apps update push rules only at app startup or resume. It creates unexpected behavior for users if they change push rules on another clients.

Glossary:

• push: json data received by the app in background to indicate there might be a relevant message for the end-user. The payload mainly contains a room_id and event_id
• notification: human readable content displayed in the OS notification system of the user device

[jplatte]

the app has a queue of incoming pushes to resolve.

and

iOS expects 1 notification per push

seem kind of conflicting to me. Why have a queue when every process created from push is only allowed to create a single notification? Overall I think it will be easiest for each push process to

1. Acquire a shared file-based lock to enforce sequential execution of push processes running in parallel (are file-based locks fair, i.e. the process waiting for the lock first will be able to unlock it first?)
2. Check if all data required to create a notification is already there (e.g. because of a sync done by the process that previously held onto the lock), if yes skip to 4
3. Sync similar to main process, store e2e keys in the DB
4. With all keys and other necessary data (hopefully) available now, evaluate push actions and display notifications if push actions say so

[manuroe]

On iOS, all notifications are handled by the same process, this is the Notification Service Extension (iOS people often call it NSE).

The OS makes an async call to NSE for every received push. The NSE returns the notification content for each async call.

Basically each iOS app extension runs on its own process. We have those processes:

• Main app process
• Notification Service Extension process
• Share Extension process
• Siri Extension process

[Velin92]

this has been completed by merging #1869