RUMM-1691 Reduce utilization of CTTelephonyNetworkInfo to mitigate CarrierInfoProvider crash

[ncreated]

What and why?

📦 This PR updates the way we retrieve CarrierInfo information on iOS 12+. It's an educated guess to mitigate infrequent (2 impacted users) crashes reported in #623 and #619. Instead of pulling CTTelephonyNetworkInfo for each collected event to create CarrierInfo, now we only listen to CTTelephonyNetworkInfo changes to update CarrierInfo when necessary.

We use CTTelephonyNetworkInfo (from CoreTelephony framework) to read carrier information:

A loop of investigation, research and debugging, lead me to following conclusions:

• C1. Reported crashes are very infrequent (one report on iOS 14.8 and one on iOS 14.6),
• C2. I observed is that CTTelephonyNetworkInfo only changes when swapping SIM card to another one (it does not change when removing SIM card - the last known info is still available). This is the only example listed in Apple doc.
• C3. We already had similar issues with utilization of Apple networking frameworks:
  • recent crash on polling ProcessInfo.isLowPowerModeEnabled,
  • old issue with pulling NWPath.currentPath .

Both issues in C3 were fixed by changing from pulling model, to subscription model (it was also a recommendation I received for NWPath issue from Apple's engineer). Given that CTTelephonyNetworkInfo changes are very infrequent (C2) it makes no sense to pull this value and compute Datadog.CarrierInfo for each event we collect. Instead, we can listen to CTTelephonyNetworkInfo changes and update Datadog.CarrierInfo only when necessary.

I can't confirm if this fixes the crash, because I didn't manage to reproduce it even when stress testing our SDK with ~500logs/s sent from iPhone X and swapping between different SIM cards during the test.

How?

Now, we use serviceSubscriberCellularProvidersDidUpdateNotifier available on iOS 12+ to update CarrierInfo. Initial value is read when SDK starts.

The logic for iOS 11 remains the same with the difference that now we also read initial value for CarrierInfo when starting the SDK. Although there is an API for listening to CTTelephonyNetworkInfo updates on iOS 11, it is deprecated (ref.: CTRadioAccessTechnologyDidChange ) and because we have no reports for iOS 11, I decided to not change existing logic.

Last, I added simple utility to stress test Logging feature in Example app:

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference

[maxep]

I see a retain circle of networkInfo in iOS12CarrierInfoProvider.

Now that makes me wondering if it worth adding this complexity just in case the user swap their sim card during a session 🤔 we could just fetch the carrier when initialising the sdk. I understand this not being a trade-off we want to take, just asking :)

[ncreated]

Now that makes me wondering if it worth adding this complexity just in case the user swap their sim card during a session 🤔 we could just fetch the carrier when initialising the sdk. I understand this not being a trade-off we want to take, just asking :)

I get the point 👍. Two things though:

• With this PR, we now "fetch the carrier when initialising the SDK" (vs. pulling it all the time before). The notification block added in this PR only fires when the SIM card is swapped, so I don't consider this a big complexity. IMO this is the minimal complexity we can add to support this case.
• About swapping SIM card being an "edge case" - this is an assumption that I'd rather avoid making. Our mission is to be the go-to place for troubleshooting and sometimes having a trace of "error happens after SIM card is replaced" could be priceless.

[maxep]

Yes, I'm convinced now :)

[maxep]

LGTM 👌
I've just a minor suggestion