feat: invalidateRemoteConfigsCache() + remote config refetch after same-uid identify (DEV-1236)

[SpertsyanKM]

B4 from the Remote Config targeting review (dash-mono PR #674). Linear: DEV-1236. Prerequisite of arming server-side dynamic targeting re-evaluation (B2a) in production: re-evaluation is invisible while the SDK serves configs from its process-lifetime in-memory cache.

What changed

1. identify() resolving to the SAME uid now drops the cached remote configs. The first identify does not change the uid (UPDATE client SET external_identity), so the cache was never invalidated on login and the user stayed on the pre-login targeting evaluation until process restart. The drop is non-destructive: loading states, pending callbacks and the in-flight generation guard survive; the pending-request replay runs strictly after the invalidation, so queued completions fetch a fresh evaluation with the attached identity and user properties. No permissions-cache clear, no re-launch — pinned by the updated identify contract tests (including the order and the repeat-identify early return).
2. New public API Qonversion.invalidateRemoteConfigsCache() — marks the cached configs stale on demand. The name says exactly what it does: no network request, no callback; the next remoteConfig / remoteConfigList call fetches a fresh targeting evaluation. Use cases in the KDoc: property batches the targeting depends on, long-session foreground returns; the doc also states you need it neither after identify (automatic) nor to recover from a bundled fallback (fallbacks are never cached). Not needed after identify() — that path is automatic.
3. Happens-before for any-thread callers. The invalidation generation is an AtomicInteger bumped synchronously on the caller thread, and every cached config carries a generation stamp — the cached fast paths serve it only while the stamp matches, so a load issued right after the invalidation never serves the stale copy even before the posted main-thread cleanup drains.
4. Superseded in-flight loads are re-issued, never worse than before. If the generation moves while a remoteConfig request is flying and callbacks await it, the load is re-issued instead of delivering the stale evaluation. The waiters are snapshotted and carried through the retry with the superseded (but valid) evaluation as a baseline — a failed retry delivers the baseline as a success instead of an error. The re-issue is gated on the loading state still being live (a user switch must not fire a request nobody awaits). An in-flight remoteConfigList completes with the evaluation it started with (documented; re-issuing a list would multiply the retry cost across N keys for a one-shot completion — recorded so nobody "fixes" the asymmetry); nothing from it is cached. Cache hits drain queued waiters (a warm state must never strand them) and flush pending user properties (parity with iOS).
5. Fallback configs are no longer cached (single-key and list paths): a bundled fallback delivered on network failure previously pinned itself into the cache until the next invalidation; now the next call retries the network. ApiRateLimitExceeded became fallback-eligible scoped to remote configs only (a local shouldFireRemoteConfigFallback predicate; the shared shouldFireFallback and the entitlements path are untouched), so offline repeat calls that hit the local limiter still receive the bundled payload instead of a hard error. A failed retry of a superseded load prefers the stashed baseline over both the error and the bundled payload — a real user-specific evaluation seconds old outranks shipped-in-binary defaults — and the guarantee is uniform: late joiners during the retry window get the baseline too.
6. Every invalidation seam bumps synchronously — the caller-thread generation bump covers attach/detach and onUserUpdate, not only the public API, so an attach from a background thread makes the cache immediately stale for main-thread readers.

Behavior changes for existing integrations (release notes)

• A remoteConfig() request in flight when identify() completes is re-issued, so its callback resolves after two round trips instead of one (correct-data-for-latency trade; a failed retry falls back to the first response, so reliability is not reduced).
• Fallback configs are no longer cached: offline apps issue one fast-failing request per read instead of one per session, recover automatically when connectivity returns, and receive the bundled payload even when the local rate limiter short-circuits the request (remote configs only — rate-limited entitlement checks are unchanged).
• A warm remoteConfig() / remoteConfigList() cache hit now flushes pending user properties (parity with iOS) — a previously purely-local read can issue a properties POST when properties are pending.
• New abstract member on the public Qonversion interface → minor version bump; anyone with a custom implementation of the interface must add invalidateRemoteConfigsCache().

Tests

QRemoteConfigManagerTest: invalidation folded into the shared entry-point loop (5 entry points, non-destructive semantics); focused re-issue tests (awaited / non-awaited / attach path); background-thread confinement test asserting immediate staleness via the generation stamp; concurrent invalidate-vs-load stress test; fallback non-caching tests. QProductCenterManagerIdentifyContractTest: same-uid pins verifyOrder(invalidate → handlePendingRequests) plus onUserUpdate exclusion; repeat-identify early return pinned. testDebugUnitTest (32+4 green), detektAll, :sample compile green.

Sample: an "Invalidate Remote Configs Cache" button on the Remote Configs screen.

Facade delegation (QonversionInternal) is a 1-line pass-through; the repo has no facade-level tests, consistent with the existing precedent.

iOS mirror and cross-platform wrappers follow in the same Linear issue. Release note: ships together with the A6 fixes (#852) in one release.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y4V5cx2SMU4VrfPntwfKJ9