This only applies to chat connections (including registration), and
for the time being is specifically looking for self-signed
certificates. Even though self-signed certificates can occur on any
network access, there should always be a chat connection early enough
in the app lifetime to identify the problem. (Other connections will
still log the error appropriately.)
And expose an explicit setInvalidProxy, both for testing and in case
apps want to do their own connection-poisoning.
This makes it easier to be consistent about "if you try to set a proxy
that turns out not to be valid, the ConnectionManager should end up in
the invalid state until explicitly cleared", whether the validation is
done on the Rust side of the bridge or the app language side.
This takes a full set of components describing the connection to a
proxy: a scheme, a host, and optionally a port and auth information.
The previous `setProxy(String, u16)` signature is still available for
Signal TLS proxies in particular, but now we have the flexibility to
support other kinds of proxies as well.
This takes a full URL (as a string) to use as a proxy. The previous
`setProxy(String, int)` signature is still available for Signal TLS
proxies in particular, but now we have the flexibility to support
other kinds of proxies as well.
Wrap the raw pointers exposed across the bridge as named types that approximate
Swift's OpaquePointer?. Parameterize NativeHandleOwner with the native handle
type.
- All public Swift-defined structs except CdsiLookupResponse,
which wraps LookupResponseEntryList, which can *probably* be made
Sendable but I didn't spend time on it.
- All public Swift-defined enums except those being used purely as
namespaces.
- All zkgroup types, since they are immutable and can be serialized
and deserialized to send them anyway
- ServiceId and its subclasses, an immutable class hierarchy
- ProtocolAddress, PinHash, SenderCertificate and ServerCertificate,
and all public and private Key types, immutable wrappers around
immutable Rust objects
More of our wrapper types could be made Sendable as well if there's a
need to. See CODING_GUIDELINES for more info.
...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.
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.
