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.)
And consolidate the implementations of these two separate checks; now
they both check for a valid session by looking for a sender chain
instead of just *some* current session, in addition to the new check
for an expired unacknowledged session. At the Rust level, this is now
one check named has_usable_sender_chain; at the app levels, the old
names of hasSenderChain (Java) and hasCurrentState (Swift, TypeScript)
have been preserved.
Tests to come in the next commit.
Like ProtocolAddresses in 88a2d5c, these APIs will eventually only
support ACIs, so introducing strong types now helps move in that
direction. However, the existing APIs that produce strings have not
been removed yet.
These work the same as the equivalent factory methods on ServiceId,
but throw if the resulting parsed ServiceId doesn't match the specific
type you were trying to parse.
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.
In a future release ProtocolAddresses will *only* support ServiceIds,
so these APIs are designed to be the nullable version of the signature
they'll eventually have. Since ProtocolAddresses are created by the
client app in nearly all cases, they should be able to ignore the null
case if they only use ServiceIds in their input.
This is a minimal change to not lose information that we already have
in Rust; there may be further changes in the future (such as avoiding
the redundancy now in ProtocolNoSessionException, or splitting out
missing Sender Key sessions, which don't have an address, from missing
Double Ratchet sessions).
