Refactor how backend handle notifications

[iamdey]

• batch operations should emit one notification only, at end of batch.
• notification model should handle multiple sub-notifications
• add generic notification model for new messages, whatever the emiter is
• allow to request notifications range by notification-id
• add discussion_id into new message notifications

[iamdey]

after discussion, notif structure:

{
  emmiter: …,
  type: "new-messages",
  notif_id: …,
  body: {
    size: N,
    elements: {optional} [
      { message_id: <str>, discussion_id: <str> },
      …
    ],
  }
}

elements is undefined when the number of new messages is over 20.

the discussion_id is the last known id so it might not match the id stored in a tab (client side).

[iamdey]

on the client, we need to parse the new scheme since all new notifs go like previous post

when receiving notifications:

• filter notifs using ?last-notif-id (FIXME)
• iterate on «batches» (type new-messages)
• update timeline
• invalidate opened discussions

-> this way we can't display how many new messages have been received

or eventually filter on discussion_ids found in batchs …