RUMM-2562 Correct the way we handle orientation change events in SR

[mariusc83]

What does this PR do?

This PR fixes the way we are handling the orientation change for Session Replay. Previously we were handling this in a separated flow which introduced a new state into the SnapshotProcessor causing problems regarding the new view detection and the order of the records. With this new approach we are handling the OrientationChanged event in the same stack used for handling the screen snapshot and by doing this we eliminate the potential issues resulting from introducing a new state for the SnapshotProcessor.

Motivation

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 #1073 (87fc25d) into feature/session-replay-vo (ff9a1cf) will decrease coverage by 0.04%.
The diff coverage is 95.24%.

@@                      Coverage Diff                      @@
##           feature/session-replay-vo    #1073      +/-   ##
=============================================================
- Coverage                      82.45%   82.41%   -0.04%     
=============================================================
  Files                            346      347       +1     
  Lines                          11179    11180       +1     
  Branches                        1849     1853       +4     
=============================================================
- Hits                            9217     9213       -4     
- Misses                          1378     1383       +5     
  Partials                         584      584              

Impacted Files	Coverage Δ
...tadog/android/sessionreplay/processor/Processor.kt	0.00% <0.00%> (ø)
...droid/sessionreplay/processor/SnapshotProcessor.kt	93.75% <100.00%> (-0.06%)	⬇️
...d/sessionreplay/recorder/RecorderOnDrawListener.kt	86.96% <100.00%> (+0.59%)	⬆️
...id/webview/internal/rum/WebViewRumEventConsumer.kt	76.74% <0.00%> (-9.30%)	⬇️
...ain/java/com/datadog/opentracing/PendingTrace.java	56.03% <0.00%> (-2.59%)	⬇️
.../android/rum/internal/monitor/DatadogRumMonitor.kt	91.91% <0.00%> (ø)
...android/v2/core/internal/DatadogContextProvider.kt	82.81% <0.00%> (ø)
...android/v2/core/internal/net/DataOkHttpUploader.kt	94.52% <0.00%> (ø)
...rsistence/file/batch/PlainBatchFileReaderWriter.kt	89.22% <0.00%> (+0.98%)	⬆️
...android/rum/internal/ndk/DatadogNdkCrashHandler.kt	87.83% <0.00%> (+1.06%)	⬆️

[0xnm]

nit: maybe isTimeForFullSnapshort (but yeah , this may not sound better)?

[0xnm]

why do we rename this? imo without resolve it also looks reasonable.