No behavior change, just moving code into named functions to improve
readability and maintainability, and applying some Python conventions.
Co-authored-by: moiseev-signal <122060238+moiseev-signal@users.noreply.github.com>
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.
...by looking for the x-signal-timestamp header, which won't be set by
some intermediate server. For other connections, we don't (yet?) have
anything to key off of, so they'll continue conservatively treating
any HTTP response as having come from the real server.
The *contents* were already identical, but jars preserve timestamps by
default, and might not sort their inputs. Fortunately Gradle has
options for both of those.
Similar to the previous commits, but for Java/Android. If invoking
build_jni.sh directly, use `--debug-level-logs` like build_ffi.sh.
As a consequence, LOGGING IS NO LONGER AUTOMATICALLY ENABLED FOR
JAVA/ANDROID. Clients must call SignalProtocolLoggerProvider.
initializeLogging() in addition to setting a provider.
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.)
