This PR integrates a post-quantum ratchet (SPQR) into libsignal, using an API that maintains its own internal chain and provides per-message keys. In doing so, it also aims to be fully backwards-compatible with current clients and stored session state.
## Backwards compatibility with current clients
Remote clients that connect to us or that we connect to may not have this integration. If they don't, their SignalMessage wire format should still deserialize, and in doing so we'll receive an empty pq_ratchet field. SQPR handles this internally, by downgrading the protocol version to "version 0" or "don't do anything". Note that should we eventually want to disallow this, we can do so via increasing the `min_version` field passed into the SQPR init functions to V1. This is also the method by which we would upgrade SQPR from v1 to a future v2, etc.
## Opt-in
The publicly facing API calls for this now expose an explicit opt-in via a passed-in `use_pq_ratchet` bool (and associated enums in language-specific APIs). If false, they default to SQPR `v0`, IE: none. If true, they try to set up SPQR on new sessions, but will downgrade if the remote party cannot or will not do the same.
There should be no reason for a client to split up devices of the same
recipient in a non-contiguous manner, but since we'd have to check it
anyway, we might as well accept it. (Duplicating devices within a
recipient can then be checked separately.)
For the most part this should happen transparently without any
explicit adoption, like the previous change, but for Java code the
NoSessionException is now properly declared on SessionCipher.encrypt.
(This was always technically possible, but clients were expected to
have previously checked for session validity before using
SessionCipher; now that there's an expiration involved, that's not
strictly possible.)
Only the iOS client ever used this extra parameter, and it's one
that's easily stored alongside the reference to a store. This is
massively simpler than having it threaded down to the Rust
libsignal_protocol and back up through the bridging layer.
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.
