Use a similar strategy as for Node, but with an additional crate that serves as
the target for running cbindgen. The expectation is that since iOS links with
the native signal_ffi statically, the linker will be able to prune out the
unsued test-only code.
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.
Separate `libsignal-bridge` into two crates:
- `libsignal-bridge-types`, which contains types and methods for bridging,
declares conversion traits, and implements those traits
- `libsignal-bridge`, which defines `extern "C"` functions that get exported
into the app-language libraries
This will allow creating a second test-only crate, parallel to
`libsignal-bridge`, that can use the same types and macros for exporting
functions.
Now there's a trait, FfiError, which handles conversion to a string
and numeric code, and a helper struct SignalFfiError that mostly just
wraps `Box<dyn FfiError>`. This makes it easier to add new errors --
they only need to be added in two places (a trait impl and possibly
new error codes) instead of three.
This allows enabling debug- and trace-level logs even in a release
build. (This also means the job of filtering *out* those logs has been
moved up to build_ffi.sh, where previously it was specified in the
leaf crate's Cargo.toml.)
...and pass that struct by reference.
This has some benefits and some drawbacks:
+ Type inference is (usually) more reliable; invokeAsyncFunction no
longer needs a "returning:" parameter for disambiguation.
+ We can add more fields to the promise structs as needed.
+ We can use the same argument for input and output.
- Before, every promise that produced an OpaquePointer could share one
protocol implementation on the Swift side. Now, they're separate.
- The manual type erasure code in the implementation of Completer has
gotten worse.
- Using the same argument for input and output may be confusing.
This ensures that if there's an error setting a proxy, the previous
settings won't continue to be used for new connections.
This only applies to the Java, Swift, and TypeScript layers; the Rust
layer's set_proxy isn't a fallible API in the first place today. The
Java API now explicitly throws a checked IOException instead of
IllegalArgumentException.
Some ring symbols aren't making it into libsignal_ffi.a otherwise. Not
totally sure why, but this makes the debug build more like the release
build anyway. It does slow down the build a bit, though, sorry.
And adjust the existing ENCLAVE_SECRET tests and examples to use this
(including Rust and Node's).
This also requires adding an AndroidManifest.xml that notes the tests
might use the network.
Treat the first 16 bytes of the stream as the IV for the AES block cipher. This
is incompatible with the previous scheme, where the IV was derived from the
master key.
