we have new OutboundP2PMessages - we have to start processing them

debug leftover

We want to fetch all messages each time because:

1. We need to make sure the order is correct, so when encrypting or sending we want to start from the oldest.
2. If something went wrong in the previous iteration, we want to attempt to start again.

The only improvement here is that in getAllOutboundP2PMessages we should query all messages but not with sent status - creating a follow-up task for it.

grouping all messages by device - when there is no session or we can not create a session with device we might want to skip the rest of messages

we need to consider how to detect when messages for a device which is not in a peer list anymore can be deleted - creating a followup task for it

this is used three times below - creating lambda to avoid code duplication

We should filter if this is an error caused because of not existing session or a malformed session, but there is incompatibility in error messages thrown from the web and native, going to create a follow-up task for it.

This code is for a not existing session, when the session is malformed we should also add a code to resend messages, this will be addressed in Resending messages to peers.

if this failed we could ignore that device, but on next run we'll attempt again

we also might want to consider:

1. Running this on app start
2. Running this after a specific time (if there are no changes in DB but still want to send not yet send messages)

1. When there is no promise - spawn the promise processing messages
2. When a promise is running - flip the switch (restartPromise) saying that if the promise is finished it needs to start again because something in DB changed (to avoid spawning multiple promises in parallel)

debug leftover

I see this pattern somewhere in the codebase where Context render another one - I think here it makes sense as PeerToPeerProvider is done using Tunnelbroker, but I am open to update this

adressed - the message was prepared to be sent to other peers but it's not encrypted. It was inserted into DB in the same transaction as making changes to the own store. For example, when adding a keyserver it's important to in the same SQL transaction update our keyserver_store and prepare messages to all devices at the same time. (I think this could be renamed but not sure about a better name).
encrypted - it was encrypted, encryption is done in the same transaction as the persisting crypto module to message order is also tracked on the client side, this means the message can be sent.
sent - the message that was sent to another peer (Tunnelbroker has it), we don't do anything about it, just wait for the confirmation (confirmation handled in peerToPeerMessageHandler)

ENG-833

In our case ciphertext is the stringified EncryptedData. If you think this is misleading we can rename it but this will require adding migration to update SQLite schema

ENG-8333

ENG-8334

Might be good to add these as code comments. It seems useful for understanding the code

done

adressed is missleading. How about persisted?

done