Prevent stale configuration data after iOS device restore

[tusharkhandelwal8]

This PR addresses the critical issue where Remote Config would fail to fetch new data and get stuck on default values after an iOS device was restored from a backup. It implements a two-part solution:

1. Fixes a Logical Initialization Race to ensure the necessary resetUserDefaults logic runs.
2. Fixes a Data Race on a global flag to eliminate a Thread Sanitizer warning.

[ncooke3]

/gemini review

[gemini-code-assist]

Code Review

This pull request effectively resolves two race conditions in the Remote Config initialization process. The first fix correctly addresses a logical race condition by ensuring database setup completes before its state is read, using a blocking wait on the database operation queue. The second fix eliminates a data race on the gIsNewDatabase global flag by synchronizing all read and write access through a dedicated serial dispatch queue. The changes are well-implemented and include clear comments explaining the reasoning. I have one minor suggestion for code conciseness.

[ncooke3]

@tusharkhandelwal8 there are several dispatch_syncs going on here. If we're on the main queue when dispatching synchronously, we could hold up the main queue and risk deadlocks. Is there a way to make the synchronization of the property asynchronous?

[ncooke3]

cc: @morganchen12

[morganchen12]

Looks like this is fine as-is. The work done on the synchronizing queue is only ever:

• read a global variable
• write a global variable
• nothing (empty block to synchronize)

In the future a more ideal architecture would either be to initialize asynchronously and then overwrite the database with the backup-restored data, or just initialize synchronously on the main thread instead of doing async initialization and then using a locking mechanism to wait for it. @tusharkhandelwal8 if you have the time you could try profiling app launch with this patch to see how the dispatch_sync affects launch times.

Regardless, I'm fine with approving this as a temporary fix.

[tusharkhandelwal8]

Thanks for the suggestion on profiling!
I profiled the app launch with the dispatch_sync patch to assess the performance overhead. The synchronization block almost increased 0.3% of the total measured App Launch Time in the test environment. Given the extremely low impact, this synchronous block seems like a good solution for now.

I agree that a fully synchronous or fully asynchronous initialization would be the long-term architectural goal.