native: add query traces to Firebase performance

[davidisaaclee]

• Installs @react-native-firebase/perf, disabling automatic instrumentation
• Adds feature flag for enabling instrumentation collection + reporting. This flag's description is long, so it exposed a layout bug in the feature flag screen – fixed with Prevent switches from getting shrunk
• Fixed some bugs introduced by native: use zustand for feature flags to enable reactivity #3848
  1. new flags would not get their default values if the device had an already-stored flag state Fix new flags not getting defaults when overwritten by stored values (this wasn't a real issue yet because we haven't added any new flags since that PR was merged)
  2. loaded flags were being inserted as state in the store, not as ...state – so loading/saving multiple times ended up with a recurring nested flags object :( I don't understand why this was okay by Zustand's types – 3949602 fixes this in a way that should avoid similar bugs in the future
  3. native: use zustand for feature flags to enable reactivity #3848 introduced a race where we attempted to save the default values when we loaded them, overwriting the user's saved settings – this often did not matter, since we would immediately re-save the loaded user's settings. fixed in 3949602 by waiting for the initial load before subscribing to store changes.
• Adds a performance React context (it's not actually a context, but looks and acts like one) that lets anything capture a custom trace
• Measure trace for every query performed via createQuery – see the query.* traces under Custom traces here: https://console.firebase.google.com/u/2/project/tlon-groups-mobile/performance/app/ios:io.tlon.groups/trends

The design of the performance monitoring code is a little abstract – this was necessary due to dependency constraints:

• @tloncorp/shared got broken after I added @react-native-firebase/perf as a dependency
• @tloncorp/shared has the feature flag setup, so the code enabling/disabling instrumentation needs to reference shared
• To measure queries, createQuery (in @tloncorp/shared) seemed like the only reasonable place to hook in. (It seems like use-query should have some kind of global pre/post hooks, but I could not find anything.) So @tloncorp/shared needs to be able to call into the performance monitoring controller.

To resolve:

• @tloncorp/shared has a performance monitoring controller usePerformanceMonitoringStore that is agnostic to the performance monitoring "endpoint", abstracting that as an injected PerformanceMonitoringEndpoint interface
• usePerformanceMonitoringStore is used in createQuery to measure queries
• @tloncorp/app implements a PerformanceMonitoringEndpoint using @react-native-firebase/perf, and registers it on the usePerformanceMonitoringStore via a provider component
• tlon-mobile mounts the context provider near root, hooking everything up

How did I test?

• Do we send instrumentation without user content? I clean-installed app, inserted a fake custom trace on a button press, pressed button – checked Firebase console after a delay, no trace recorded. Enabled instrumentation via flag, changed ID of custom trace, triggered that trace, checked console – trace was recorded.
• Does this instrumentation slow down queries? I set up a button to call getGroup on a real group serially, 800 times; ran it once without any instrumentation code, and once with instrumentation enabled. There was less than 1ms of difference for the averaged query duration.
• Does this work on Android? Yes, running in Android emulator acts the same as in iOS: does not apparently send traces to Firebase until feature flag is toggled; then, only custom traces are sent to https://console.firebase.google.com/u/2/project/tlon-groups-mobile/performance/app/android:io.tlon.groups/trends (different page than iOS)

Example dashboards

[arthyn]

lgtm! curious to see what this does

[davidisaaclee]

added some screenshots of what the Firebase dashboards look like – I think the immediate benefit is seeing when a new release significantly changes the duration or volume of queries. We are currently not using HTTP request traces (I don't know if this makes sense for Tlon – maybe if we restrict to only Tlon hosting endpoints?); and we're not using "screen traces", which supposedly reports "slow rendering / frozen frames" (when I tested this with the basic setup, it seemed to only detect generically-named React Native screens, so I think we'd have to adapt it for our usage).