RUM-4098: Use the datastore for Session Replay resources

[jonathanmos]

What does this PR do?

Use the datastore from Session Replay, so that resource hashes are persisted between sessions.

Motivation

The second part of the effort to persist bitmap hashes between sessions.

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 87.50000% with 13 lines in your changes missing coverage. Please review.

Project coverage is 83.22%. Comparing base (d8d0838) to head (fa9f3b1).
Report is 1 commits behind head on develop.

❗ Current head fa9f3b1 differs from pull request most recent head 4641fbf

Please upload reports for the commit 4641fbf to get more accurate results.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop    #2041       +/-   ##
============================================
+ Coverage    69.56%   83.22%   +13.67%     
============================================
  Files          715      511      -204     
  Lines        26553    18119     -8434     
  Branches      4452     2719     -1733     
============================================
- Hits         18469    15079     -3390     
+ Misses        6871     2293     -4578     
+ Partials      1213      747      -466     

Files	Coverage Δ
...rnal/persistence/datastore/DataStoreFileHandler.kt	100.00% <100.00%> (ø)
...ernal/persistence/datastore/DatastoreFileReader.kt	95.56% <ø> (ø)
...rnal/persistence/datastore/NoOpDataStoreHandler.kt	100.00% <ø> (ø)
.../sessionreplay/internal/DefaultRecorderProvider.kt	93.10% <100.00%> (+0.06%)	⬆️
...oid/sessionreplay/internal/SessionReplayFeature.kt	100.00% <100.00%> (ø)
...replay/internal/processor/RecordedDataProcessor.kt	97.67% <100.00%> (+0.17%)	⬆️
...nreplay/internal/recorder/SessionReplayRecorder.kt	96.69% <100.00%> (-0.11%)	⬇️
...ernal/resources/ResourceHashesEntryDeserializer.kt	100.00% <100.00%> (ø)
...nternal/resources/ResourceHashesEntrySerializer.kt	50.00% <50.00%> (ø)
.../android/api/storage/datastore/DataStoreHandler.kt	20.00% <0.00%> (-13.33%)	⬇️
... and 2 more

... and 265 files with indirect coverage changes

[0xnm]

what us the use-case when we are interested in the result?

[jonathanmos]

For when we remove the expired datastore entry, because this is an async operation and therefore we need to know when it's finished in order to be sure that the initialization of the datastoremanager is complete.

[0xnm]

what us the use-case when we are interested in the result?

[jonathanmos]

At the moment for setValue there is no specific use-case, but I felt that it makes sense to also have a callback here, since we have one for removeValue

[0xnm]

probably not the most efficient design. Imagine you have 1000 hashes, each is 36 characters (UUID length). All chars are ASCII, so each char is 1 byte. It means that once you add 1001th hash, you need to write (and also serialize) all 1000 hashes you wrote before, which is 36KB. So with each write operation you have data overhead of 36KB, instead of storing only the hash you need to.

[jonathanmos]

after discussion, we'll leave this for now and perhaps improve in a future pr

[0xnm]

minor: there is no need to have this argument, because the only call site of this method gives empty lambda.

[jonathanmos]

This lambda should actually not be empty but should have a call to finishedInitializingManager. I'll add some tests to catch missing calls

[0xnm]

note: if performance is critical here, it is better to use Collections.newSetFromMap(ConcurrentHashMap<String, Boolean>). Overall the performance of ConcurrentHashMap is better that synchronised map (but there are some differences in behavior).

[jonathanmos]

Good point - I've modified this

[0xnm]

lgtm. but my concern about writing all the hashes each time we just need to add one more to storage stays, not sure how much it can become a bottleneck in the app with many resources.