There were two discrepancies between the logic here and the original
logic of libsignal-protocol-java.
First, if the session record had an uninitialized active session, in
Java this would still attempt decryption with the old session states,
but Rust would stop immediately without trying the old states. [I am
not sure if this ever happens but it could possibly occur due to use
of archiveCurrentState]
Secondly, we returned the wrong error condition. We treated lack of a
sender chain as an invalid state (effectively an internal error) but
Java treats it as an invalid message, which makes sense in so far as
it is a message which we are unable to process with the information we
have available. This wrong error type led to an unexpected exception
being thrown in Android.
These are here just to copy the Java SessionCipher API but if you
need this just load the session record from your store.
[The Java library does exactly this, without bothering to call the
Rust version]
These still need to be exposed for the Java tests but they only
need to see the SessionRecord not the SessionState.
The internal functions still need to return a SessionState due to how
these functions are used within the crate.
In preparation for Desktop, which must asynchronously access its
database (rather than putting the entire operation on a background
thread with synchronization at the database layer).
The FFI and JNI wrappers (as well as the tests) use
futures::executor::block_on to turn the operations back into
synchronous ones.
