If options.messageKeysLimit is provided by falsey, then we don't apply
any limit at all. This can be used to set no limit for communications
from your own devices.
Why would you want that? People leave their laptops closed for weeks at
a time and get this error, since their other devices are sending
messages to it constantly:
"Too many message keys for chain"
And it seems to be really hard to fix once you're in this state. Sync
messages no longer show up from the device that got into this state.
FREEBIE
This reverts commit b45ace4 and parts of 2657f00.
The purpose of the deletes was so that a session with a different identity key
couldn't get "resurrected" after an identity switch. But if the validate/save
action is happening for every encrypt/decrypt, then it shouldn't be possible
for an old identity to get invisibly resurrected.
Furthermore, at the application level we would clear sessions for all devices
on the affected number, but libsignal-protocol operates on a per-device basis,
so it can only perform what amounts to an incomplete removal.
Pass in a direction to isTrusted, based on constants defined by the storage
implementation. These values allow the trust store to determine whether a given
key is trusted, given the directional context.
This check didn't work, which resulted in closing and then immediately
reopening the current session. Not that big a deal, since it merely
flips a flag off and back on again just before saving the session
record, but does result in spurious log statements.
`MessageCounterError` is the expected result of repeated deliveries.
Error handling in decryptWithSessionList should immediately return such
an error if it occurs. Previous to this change, a Bad MAC error to be
returned instead of a MessageCounterError, if the message in question
was encrypted for a closed session.
This was mostly used internally by SessionRecord to flag the lack of an
open session, but that can be replaced with an actual check for an open
session.
This is redundant to the identity key store, and only used to check
internal consistency between sessions and the 'current' remote identity,
though there's no particular reason we can't keep sessions from previous
identity keys.
The signal service requires this field to accompany outgoing ciphertexts.
With this change we can likely remove the correspinding getter from
SessionCipher.
