can't we just rely on local data from auxUserStore?

Overall this approach is not fully safe and works only because when testing this, this was the only case when we sent encrypted data to another client.

Right now, for decrypting, we use decryptSequentialAndPersist which tracks order of messages, so the following case in future is possible:

1. There is some information that the app tries to send to other peer (P1), e.g. some updates (M1).
2. M1 is encrypted but not queued on Tunnelbroker.
3. This code tries to send a logout message - M2.
4. M2 is encrypted and sent to P1.
5. P1 is unable to decrypt M2 because M1 is missing and decryptSequentialAndPersist throws an error because the ordering is not maintained.

To address that, we have PeerToPeerProvider which makes sure that messages are encrypted and sent in order from different callsties, this code should:

1. create and persist outboundP2PMessages with logout messages (persisting is not needed because we going to delete DB anyway, so we can avoid this but this requires some changes).
2. call processOutboundMessages() method from PeerToPeerProvider which encrypts and sends them in order.

However, yesterday we had a discussion with @tomek and @ashoat about different approaches, allowing mixing order of messages and making business logic resilient to this.

I think we can unblock this now, but could you create a task to document this somewhere and also make sure @tomek is aware when scoping and:

1. If we stick to tracking order - this needs to be updated as described above before we ship this.
2. If we change the approach and allow mixed order - this code is fine.

1, 2 - I can handle this when working on a task linked by @bartek.