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.
This on-connect header will be used for lightweight "alerts" from the
server to an authenticated client. For now, it's only threaded through
to the Node implementation; the iOS and Android ones will come later.
Propagating the mp4san new feature through all the layers of libsignal.
The feature allows seamless handling of transcoded MP4 files on Android, where multiple MDAT boxes (one per chunk of A/V streams) are first compounded and then passed to mp4san for format correction.
And expose an explicit setInvalidProxy, both for testing and in case
apps want to do their own connection-poisoning.
This makes it easier to be consistent about "if you try to set a proxy
that turns out not to be valid, the ConnectionManager should end up in
the invalid state until explicitly cleared", whether the validation is
done on the Rust side of the bridge or the app language side.
This takes a full set of components describing the connection to a
proxy: a scheme, a host, and optionally a port and auth information.
The previous `setProxy(String, u16)` signature is still available for
Signal TLS proxies in particular, but now we have the flexibility to
support other kinds of proxies as well.
