Adds support for callbacks with results to the JNI bridge, similar to
what f2eafbe6f8 did for the C bridge.
This does require introducing an "internal" version of PreKeyStore
that has simpler signatures for its callbacks; previously, the Java
objects for bridge_handle types were constructed on the Rust side of
the bridge, but that's not how bridge_fn works, and so it's not how
bridge_callbacks works. The additional overhead should not be
prohibitive.
This required some changes to jni::ResultTypeInfo, because we no
longer have tokens available for the JNI types of a bridged function
to use with the jni_args! macro. Instead, we record signatures for
each type that might appear as a callback argument and use
const_str::concat to put them together.
This does not currently attempt to autogenerate the Java interface on
the other side of the bridge; given the way gen_java_decl builds on
top of cbindgen, this is likely tricky but not impossible. Something
to possibly add later.
Rather than embedding a server certificate inside every sender
certificate, future sender certificates will be able to reference
their server certificate by ID as long as all receivers have a version
of libsignal containing that certificate.
This change also handles the sender ACI being represented as bytes
instead of a string.
The "fingerprint" / safety number operations *are* tied to the
"protocol" in that they provide a way to verify identity keys, but
they are also completely distinct from the message handling that the
rest of SignalProtocolError is used for.
Before
> I libsignal: rust/bridge/shared/types/src/net.rs:132: Initializing connection manager for Staging...
After
> [11:03:32.956965 libsignal] I rust/bridge/shared/types/src/net.rs:132: Initializing connection manager for Staging...
- Use a local frame for bridge_io when completing futures
- Use a local frame for ChatListener callbacks
- Use AutoLocal for exception formatting callbacks
Improvements included in this first iteration:
- Nullable/non-nullable!
- ObjectHandle typealias for Long
- Fixed handling for CompletableFuture<Void> (previously translated
without generics at all in some cases)
Co-authored-by: Alex Bakon <akonradi@signal.org>
Previously, we used a per-project directory glob for Kotlin and Java
sources, which (1) was overly general, (2) ran afoul of Gradle's rules
about "if you look in a directory you must depend on it", and (3)
required us to make a fake subproject in the shared/ folder because
Spotless doesn't like sources outside the project directory.
Now, we delay complete evaluation of the root project until
subprojects are complete, and then add a single Spotless operation at
the top level that uses the subprojects' compile tasks to find exactly
the files to format.
