RUM-985 propagate session state and view type as Strings

[xgouchet]

What does this PR do?

The RUM session_state and view_type were propagated as internal enums in the shared RUM feature context. This means that other modules could not use those values (except with a call to toString(), which could have resulted in obfuscated results).

This PR ensures the data is shared as a String, to be manipulated unobfuscated from any module using it.

Motivation

Part of the work done to make the RUM sampling consistent between Webviews and the native app.

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 #1625 (6464702) into develop (85087f3) will increase coverage by 0.08%.
Report is 3 commits behind head on develop.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #1625      +/-   ##
===========================================
+ Coverage    83.59%   83.67%   +0.08%     
===========================================
  Files          452      452              
  Lines        15661    15660       -1     
  Branches      2326     2327       +1     
===========================================
+ Hits         13091    13102      +11     
+ Misses        1945     1937       -8     
+ Partials       625      621       -4     

Files Changed	Coverage Δ
.../datadog/android/rum/internal/domain/RumContext.kt	100.00% <100.00%> (ø)
...droid/rum/internal/domain/scope/RumSessionScope.kt	95.51% <100.00%> (+0.10%)	⬆️
.../android/rum/internal/domain/scope/RumViewScope.kt	95.42% <100.00%> (+0.02%)	⬆️

... and 16 files with indirect coverage changes

[0xnm]

nice catch! another option btw is to add the rules to the proguard file we ship with the library, was it considered? anyway, I'm fine with this solution as well.

[xgouchet]

@0xnm

another option btw is to add the rules to the proguard file we ship with the library, was it considered? anyway, I'm fine with this solution as well.
I thought about it, but since those enums are internal anyway, it felt wrong to add a proguard rule for it