Unlike Java, just bundle it into the exiting signal_node shared library. We
don't care as much about code size here and splitting it into a separate
library is significantly more complicated (though it might be worth it some
day).
Remove the special handling code that detects EOF now that the upstream crate
has fixed the bug that was being worked around. This also fixes a bug where EOF
was being incorrectly detected when the provided buffer was empty. Add a test
case to prevent regression in the future.
The enclave interactions have internal progress monitoring in the form of
websocket PING/PONG frames, so the timeout parameters aren't necessary for
broken connection detection.
Specifically, make this on the Rust side bridge layer, and tack it on
to the end of per-member endorsements for the app side to peel off
later, rather than the app layer calling back down to Rust to compute
it. This saves a fair amount of marshalling work.
Add a new version of the existing auth credential used for groups, but
implemented with the zkcredential crate instead of hand-written proofs. Expose
issuance point for the server, and extend existing client methods to support it
and the existing formats transparently.
Add a flag to the CLI validation tool and an argument to the bridged validation
functions so users can specify whether a provided message backup should be
validated according to the rules for device-to-device transfers or backups
intended for remote storage.
Use the class loader from the main thread to cache java.lang.Class
instances for some libsignal classes.
This enables constructing instances of libsignal classes on threads
where the classes aren't accessible via the default class loader. This
can occur on Android, where threads spawned via the native API only get
access to the system class loader, not the application loader that has
access to the application's class files. Since Tokio worker threads are
spawned via the native API, and the completion process for async tasks
converts results to Java objects, application class instances can't be
used there unless they are preloaded.
Since classes used in client code are only included in the client .jar
file, failure to load classes is a normal occurrence. If there are ever
separate builds for server and client .so library files, this could be
changed to a fatal error.
CDSI error handling code would attempt to instantiate a nonexistent Java class.
Add the missing class and split up the handling for CDSI lookup errors to reuse
existing error types.
Use the string bridging code introduced previously to provide string arrays to
client directly instead of joining and splitting. This eliminates the use of a
magic ',' character as a delimiter.
