RUM-1654 Add resourceId to ImageWireframe

[jonathanmos]

What does this PR do?

Adds the resourceId property to ImageWireframe, and additionally removes base64 from the MutationResolver diffing.

Motivation

Removing base64 from diffing improved performance on ios and in this PR we align on this change. Additionally, resourceId is a necessary prerequisite for the resource endpoint change.

What inspired you to submit this pull request?

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

Merging #1690 (b76e2f4) into develop (99ddc9a) will decrease coverage by 0.08%.
Report is 9 commits behind head on develop.
The diff coverage is 75.51%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1690      +/-   ##
===========================================
- Coverage    83.32%   83.24%   -0.08%     
===========================================
  Files          466      467       +1     
  Lines        16192    16238      +46     
  Branches      2413     2425      +12     
===========================================
+ Hits         13491    13517      +26     
- Misses        2043     2052       +9     
- Partials       658      669      +11     

Files	Coverage Δ
...ssionreplay/internal/processor/MutationResolver.kt	89.27% <100.00%> (ø)
...roid/sessionreplay/internal/utils/DrawableUtils.kt	98.44% <100.00%> (-0.02%)	⬇️
...eplay/internal/recorder/base64/Base64Serializer.kt	96.64% <92.59%> (+7.01%)	⬆️
...eplay/internal/recorder/base64/MD5HashGenerator.kt	53.33% <53.33%> (ø)
...nreplay/internal/recorder/base64/Base64LRUCache.kt	62.71% <48.00%> (-12.90%)	⬇️

... and 22 files with indirect coverage changes

[0xnm]

So what backend does if there is no resourceId, but other payload like base64, etc. is there. How resourceId is used?

[jonathanmos]

at the moment backend is using base64, and eventually will map rssId as the key to pull the binary for use in the replays. In the future when the rss endpoint is done, there will have to be some logic there for ending support for b64 and moving over entirely to rssId (we'll start to send b64 as an empty field in the wireframes and only populate rssId)

[0xnm]

So what will be our logic then if we cannot generate resourceId? We won't send a resource itself then? This 99.999% won't happen (all devices for sure can generate MD5 hash), but I'm just curious.

[jonathanmos]

If we can't generate the hash then I think we'll need to throw away the binary because backend won't be able to use it in a replay. We can check for this in the future by having the rssId inside the recordedDataQueueItem holding the binary and marking it as invalid if the field isn't populated, then the dataQueueHandler can purge the record

[0xnm]

lgtm! I left some comments, but they are not blocking.

[0xnm]

To be precise, base64 is not a hash, but encoding.