RUM-4516 flag critical events in custom persistence

[xgouchet]

What does this PR do?

Adds an additional flag when writing event to let storage handle those differently.

Motivation

Because some users with custom PersistenceStrategy use mainly a memory based storage, they need to know when the app is about to crash in order to persist the data in a way that can be retrieved after an app reboot.

Additional Notes

An additional type was created for telemetry, just to be able to distinguish it.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.97%. Comparing base (a783738) to head (6fadd84).
Report is 4 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2044      +/-   ##
===========================================
- Coverage    83.18%   82.97%   -0.21%     
===========================================
  Files          493      494       +1     
  Lines        17691    17709      +18     
  Branches      2681     2682       +1     
===========================================
- Hits         14716    14693      -23     
- Misses        2238     2274      +36     
- Partials       737      742       +5     

Files	Coverage Δ
...otlin/com/datadog/android/api/storage/EventType.kt	100.00% <100.00%> (ø)
...droid/core/internal/persistence/AbstractStorage.kt	100.00% <100.00%> (ø)
.../core/internal/persistence/FileEventBatchWriter.kt	97.50% <ø> (ø)
.../core/internal/persistence/NoOpEventBatchWriter.kt	100.00% <ø> (ø)
...og/android/core/persistence/PersistenceStrategy.kt	100.00% <ø> (ø)
...in/com/datadog/android/log/internal/LogsFeature.kt	84.06% <100.00%> (-1.45%)	⬇️
...g/android/log/internal/logger/DatadogLogHandler.kt	77.12% <100.00%> (ø)
...dog/android/log/internal/storage/LogsDataWriter.kt	100.00% <100.00%> (ø)
...g/android/rum/internal/DatadogLateCrashReporter.kt	84.75% <100.00%> (+0.56%)	⬆️
...tadog/android/rum/internal/domain/RumDataWriter.kt	100.00% <100.00%> (ø)
... and 10 more

... and 20 files with indirect coverage changes

[0xnm]

Overall the change looks clear to me, I left one question.

Although maybe alternative to this would be just adding something like PersistenceStrategy#flush method which could be called when crash happens, this could reduce change layout.

Or, maybe, we could say that if custom persistence strategy is used, then user is responsible for it, meaning they should register their own unhandled exception handler (but, probably, this is not a great integration experience).

[0xnm]

what do you think about adding a default value here eventType: EventType = EventType.DEFAULT in order to reduce the change layout and make this change backward compatible (just in case)?

[xgouchet]

Well that's a thought but I'm trying to limit the use of default values when it's not necessary.
IMHO, using default values makes sense for public APIs our customer might use, but for our internals, it's a source of errors since we could get lazy and not set a value we're supposed to set.

[xgouchet]

@0xnm regarding your idea to provide a flush method, it does make a sense, but IMO makes an assumption on what the implementation looks like (in this case that the custom implementation will always be an in memory).
If a customer wanted to use a local DB instead of batch files, the notion of flushing data would make no sense. Flagging the events themselves as Crash means they can add their own logic on top of it, e.g. send them first when we request data to be sent in the next intake request.