fix(firebase-perf): Update device cache only if RC value is different from cached value

[exaby73]

Fixes #6407

[github-actions]

Release note changes

The following release notes were modified. Please ensure they look correct.

Release Notes

firebase-perf

### {{perfmon}} version 21.0.3 {: #performance_v21-0-3}

* {{fixed}} Fixed a performance issue with shared preferences
  calling `.apply()` every time a value is read from remote config GitHub [#6407](//github.com/firebase/firebase-android-sdk/issues/6407){: .external}

#### {{perfmon}} Kotlin extensions version 21.0.3 {: #performance-ktx_v21-0-3}

The Kotlin extensions library transitively includes the updated
`firebase-perf` library. The Kotlin extensions library has no additional
updates.

[github-actions]

Vertex AI Mock Responses Check ⚠️

A newer major version of the mock responses for Vertex AI unit tests is available. update_responses.sh should be updated to clone the latest version of the responses: v5.1

[github-actions]

Test Results

  110 files  + 56    110 suites  +56   2m 17s ⏱️ +4s
  969 tests +454    969 ✅ +455  0 💤  - 1  0 ❌ ±0 
1 946 runs  +916  1 946 ✅ +918  0 💤  - 2  0 ❌ ±0 

Results for commit cc34082. ± Comparison against base commit 57e401c.

This pull request removes 515 and adds 969 tests. Note that renamed tests count towards both.

com.google.firebase.dataconnect.AnyValueSerializerUnitTest ‑ descriptor should have expected values
com.google.firebase.dataconnect.AnyValueSerializerUnitTest ‑ deserialize() should throw UnsupportedOperationException
com.google.firebase.dataconnect.AnyValueSerializerUnitTest ‑ serialize() should throw UnsupportedOperationException
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(Boolean) creates an object with the expected value
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(Double) creates an object with the expected value (edge cases)
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(Double) creates an object with the expected value (normal cases)
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(List) creates an object with the expected value (edge cases)
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(List) creates an object with the expected value (normal cases)
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(Map) creates an object with the expected value (edge cases)
com.google.firebase.dataconnect.AnyValueUnitTest ‑ constructor(Map) creates an object with the expected value (normal cases)
…

com.google.firebase.perf.FirebasePerfRegistrarTest ‑ testGetComponents
com.google.firebase.perf.FirebasePerformanceTest ‑ firebasePerformanceInitialization_providesRcProvider_remoteConfigManagerIsSet
com.google.firebase.perf.FirebasePerformanceTest ‑ initFirebasePerformance_injectsMetadataIntoConfigResolver
com.google.firebase.perf.FirebasePerformanceTest ‑ initializeFirebasePerformance_emptyMetadataAndCache_metadataAndContextInjected
com.google.firebase.perf.FirebasePerformanceTest ‑ setDataCollectionDefaultEnabled_whenForceDisabledThenCleared_respectsGlobalFlag
com.google.firebase.perf.FirebasePerformanceTest ‑ setDataCollectionDefaultEnabled_whenForceDisabledThenCleared_respectsManifestTrue
com.google.firebase.perf.FirebasePerformanceTest ‑ setDataCollectionDefaultEnabled_whenForceEnabledThenCleared_respectsGlobalFlag
com.google.firebase.perf.FirebasePerformanceTest ‑ setDataCollectionDefaultEnabled_whenForceEnabledThenCleared_respectsManifestFalse
com.google.firebase.perf.FirebasePerformanceTest ‑ testAddingMoreThanMaxLocalAttributes
com.google.firebase.perf.FirebasePerformanceTest ‑ testBothManifestsAgree
…

♻️ This comment has been updated with latest results.

[visumickey]

Thanks for making the change. I'm just curious as to why just these 2 flags and not other values? Is this because we are trying to optimize only the startup time performance?

[exaby73]

@visumickey The issue is every time isPerformanceMonitoringEnabled is called, if a value in RC is available, SharedPreferenced.apply() was called twice. Since this method can be called for every trace, this queued up many calls to apply() which caused the main thread to wait for a long time when it finally flushed the queue causing ANRs in many cases.

This PR is aimed to fix that specific issue, but I can't see a reason why we can't do it for all values

[visumickey]

@visumickey The issue is every time isPerformanceMonitoringEnabled is called, if a value in RC is available, SharedPreferenced.apply() was called twice. Since this method can be called for every trace, this queued up many calls to apply() which caused the main thread to wait for a long time when it finally flushed the queue causing ANRs in many cases.

This PR is aimed to fix that specific issue, but I can't see a reason why we can't do it for all values

Thanks for clarifying. Let's keep this PR narrow down to this issue. We can make the refactor to the rest of the code later.