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.

[gemini-code-assist]

For conciseness, you can place the empty block on a single line. The purpose of this synchronization is already well-documented by the comment above, so the inner comment is not strictly necessary.

  dispatch_sync(_databaseOperationQueue, ^{});

[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