Read SR system requirement synchronously with strict mode allowance

[ambushwork]

What does this PR do?

Asynchronous enabling the session replay feature after checking the system requirement causes the dysfunction of touch recorder.
This commit fixes it by reading the files on the original thread synchronously with allowance of strict mode.

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 47.05882% with 9 lines in your changes missing coverage. Please review.

Project coverage is 70.34%. Comparing base (7ebe827) to head (8a20143).
Report is 4 commits behind head on develop.

Files with missing lines	Patch %	Lines
...d/sessionreplay/SystemRequirementsConfiguration.kt	0.00%	9 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2307      +/-   ##
===========================================
+ Coverage    70.32%   70.34%   +0.02%     
===========================================
  Files          736      736              
  Lines        27466    27465       -1     
  Branches      4607     4607              
===========================================
+ Hits         19315    19319       +4     
+ Misses        6871     6858      -13     
- Partials      1280     1288       +8     

Files with missing lines	Coverage Δ
...com/datadog/android/sessionreplay/SessionReplay.kt	59.26% <100.00%> (-3.24%)	⬇️
...lay/internal/prerequisite/CPURequirementChecker.kt	76.47% <100.00%> (+3.14%)	⬆️
.../internal/prerequisite/MemoryRequirementChecker.kt	65.38% <100.00%> (+2.88%)	⬆️
...d/sessionreplay/SystemRequirementsConfiguration.kt	51.72% <0.00%> (+1.72%)	⬆️

... and 31 files with indirect coverage changes

[0xnm]

side question: while we mitigated the issue for the case when SR is initialized in the Application#onCreate and on the main thread, I believe we can still have a similar issue if SR is initialialized by the customer from the worker thread / later in the app lifecycle. Is there a way to mitigate completely?

[ambushwork]

With current solution of LifecycleCallback, I don't see a solution, once user misses the onResume event, they need to wait until the next onResume to make the touch recorder work properly

[0xnm]

If there is no solution for such case, then maybe we should highlight in the docs indeed that SR should be initialized early.

[ambushwork]

updated