This can be forced on or off using the new RemoteConfig setting:
`ios.useLibsignalForChat`.
The change will take place the *next* time the app is launched, since
the prior value of these settings (including the default, previously
always false) is recorded in UserDefaults for use during app startup.
This was turned on implicitly in libsignal v0.65.3, but was discovered
to have issues. Those issues should now be fixed, but this time we
have a RemoteConfig kill switch in case there are more. That kill
switch also needs to control the use of system proxies (cf. 1f6fea1a).
Since the threshold for reporting is an absolute count of errors,
eventually everybody on the "high" shadowing mode will see them.
Rather than make that tracking more complex right now, turn the
shadowing back down to "low", which only ever logs about issues and
does not ask the user to report them to us. We've already gotten
the signal we need.
This is a *subclass* of OWSChatConnectionUsingLibSignal, mainly
because the authenticated/identified connection really does have
capabilities the unauth/unidentified one does not, and splitting those
out makes it easier to see which are which.
For now each websocket connection, identified and unidentified, has
its own libsignal ChatService instance, even though ChatService is
designed to manage both connections together. Later on in the
migration it'll make sense to consolidate them, but under the existing
structure of OWSChatConnection this is the easiest way to manage their
lifecycles.
Controlled by new RemoteConfig flag
"ios.experimentalTransportEnabled.libsignalAuth" (and for local
testing, UserDefaults flag UseLibsignalForIdentifiedWebsocket).
The choice of whether or not to use this is controlled by a
RemoteConfig flag, ios.experimentalTransportEnabled.libsignal, but
because ChatConnectionManager is set up before RemoteConfig has even
loaded its cached settings, the flag is cached in UserDefaults, like
the shadowing kill switch setting.