RUM-5553: Add DatadogMeter to read vital data for benchmark

[ambushwork]

What does this PR do?

Add DatadogMeter to read vital data for benchmark.

With this commit, the sample application can activate the DatadogMeter by adding this:

val datadogExporterConfiguration = com.datadog.benchmark.DatadogExporterConfiguration
            .Builder(apiKey = "xxxxxx")
            .setApplicationName("Sample Application")
            .setApplicationId(BuildConfig.APPLICATION_ID)
            .setApplicationVersion(BuildConfig.VERSION_NAME)
            .setIntervalInSeconds(20L)
            .setRun("baseline")
            .build()
 val meter = DatadogMeter.create(datadogExporterConfiguration)

meter.startGauges()

meter.stopGauges()

Motivation

RUM-5553

Additional Notes

Some vital readers classes and unit tests are copied from feature modules for following reasons:

• This module should depend or use as less as possible the functionalities from SDK to get better result.
• We might have different requirements of metrics apart from the vitals for client ( for example for the cpu vital we wish to have a cpu ticks timeseries instead of a cumulative value in production) , so isolate them from SDK is easier to maintain, and will have a risk of breaking production.
• In the future we might make PR of this module to public opentelemetry-java repository, all the classes need to be independent from our SDK.

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

All modified and coverable lines are covered by tests ✅

Project coverage is 69.97%. Comparing base (63e35ed) to head (acf70d2).
Report is 2 commits behind head on feature/metric-benchmark.

Additional details and impacted files

@@                     Coverage Diff                      @@
##           feature/metric-benchmark    #2144      +/-   ##
============================================================
+ Coverage                     69.94%   69.97%   +0.02%     
============================================================
  Files                           726      726              
  Lines                         26962    26962              
  Branches                       4519     4519              
============================================================
+ Hits                          18858    18864       +6     
+ Misses                         6832     6830       -2     
+ Partials                       1272     1268       -4     

see 22 files with indirect coverage changes

[ambushwork]

@jonathanmos I just made the fix on the gauge as we discussed, please review it

[0xnm]

do we need these methods? they are originally were developed for the SDK usage, so that exception is not propagated to the client code. But if I get it right, this benchmark tooling is just internal tooling? So we probably don't care?

[ambushwork]

Indeed, the whole file will be removed

[0xnm]

why Choreographer is chosen over what androidx.metrics gives?

[ambushwork]

I didn't know androidx.metrics can do the same thing, is there any advantage of android.metrics comparing to Choreographer?

[0xnm]

yes, a lot of advantages: it is a wrapper around different new APIs allowing collecting more granular metrics. Also by registering Choreographer callback and not un-registering it when app goes into background/losing focus, you make CPU running more (this point probably doesn't matter a lot for internal tooling).

Anyway, FPS is not a good metric to judge about the performance and we were discussion to ditch it and replace it with something else (especially considering dynamic refresh rate). Much more meaningful metric will be something like the % of skipped/junky frames, for example.

[ambushwork]

Good to know, I will first make a pull request to clean up the code on all the places where you mentioned, and another dedicated commit to replace the Choreographer

[0xnm]

Overall maybe for this work we shouldn't use FPS as a metric at all. But this is just my opinion.

[ambushwork]

Maybe you are right, with current synthetics test and metrics result, we can hardly see any difference between baseline and instrumented test, I will try to see if androidx.metrics can provide some more valuable result.

[0xnm]

same question: why Choreographer over androidx.metrics?