Extra OTel components into OTel module and delay SDK init until SDK starts up

[bidetofevil]

Goal

Extract OTel components into its own module and delay the OTel SDK init until the SDK starts. This allows the SDK instance to be configured programmatically before the SDK start, like adding resources and Exporters. Most of the changes are test updates. I also added an OpenTelemetryModule implementation instance in FakeInitModule for ease of use since they need to be tied together anyway.

[bidetofevil]

Current dependencies on/for this PR:

• master
  • PR Remove Flutter methods from Embrace.java #192
    • PR Remove RN methods from Embrace.java #190
      • PR Simplify properties sanitization #358
        • PR Simplify worker module #359
          • PR Remove support for API < 21 #360
            • PR Remove duplicate VersionChecker #361
              • PR Simplify EssentialServiceModule #362
                • PR Consolidate modules init in separate component #363
                  • PR Make EmbraceTracer not depend on SpansRepository #378
                  • PR Initialize InternalTracer as singleton #379
                  • PR Extra OTel components into OTel module and delay SDK init until SDK starts up #380 👈

This stack of pull requests is managed by Graphite.

[fractalwrench]

LGTM

[fractalwrench]

We're using this pattern a lot more frequently - I wonder whether it makes sense to create a typealias that makes this a bit more explicit? E.g. something like:

internal typealias Provider<T> = () -> T

Not required for this changeset

[bidetofevil]

Good idea! Provider is a bit Dagger-esque, and Supplier is a it Java-esque, so either one would work. Lets do that after.

[bidetofevil]

Merge activity

• Feb 8, 11:32 AM EST: @bidetofevil started a stack merge that includes this pull request via Graphite.
• Feb 8, 11:37 AM EST: Graphite rebased this pull request as part of a merge.
• Feb 8, 11:38 AM EST: @bidetofevil merged this pull request with Graphite.

[codecov]

Codecov Report

Attention: 15 lines in your changes are missing coverage. Please review.

Comparison is base (a3f91b4) 78.83% compared to head (9c0d2f2) 79.00%.
Report is 4 commits behind head on master.

❗ Current head 9c0d2f2 differs from pull request most recent head c59e315. Consider uploading reports for the commit c59e315 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #380      +/-   ##
==========================================
+ Coverage   78.83%   79.00%   +0.16%     
==========================================
  Files         342      343       +1     
  Lines        9677     9720      +43     
  Branches     1452     1457       +5     
==========================================
+ Hits         7629     7679      +50     
+ Misses       1470     1456      -14     
- Partials      578      585       +7     

Files	Coverage Δ
...android/embracesdk/EmbraceInternalInterfaceImpl.kt	94.04% <ø> (-0.08%)	⬇️
...race/android/embracesdk/InternalInterfaceModule.kt	100.00% <100.00%> (ø)
...mbracesdk/UninitializedSdkInternalInterfaceImpl.kt	64.70% <ø> (ø)
...d/embracesdk/injection/DataCaptureServiceModule.kt	97.67% <100.00%> (ø)
...ndroid/embracesdk/injection/DataContainerModule.kt	100.00% <100.00%> (ø)
...ace/android/embracesdk/injection/DeliveryModule.kt	100.00% <ø> (ø)
...embrace/android/embracesdk/injection/InitModule.kt	100.00% <100.00%> (ø)
...ndroid/embracesdk/injection/OpenTelemetryModule.kt	100.00% <100.00%> (ø)
...race/android/embracesdk/injection/SessionModule.kt	98.30% <100.00%> (ø)
...race/android/embracesdk/injection/StorageModule.kt	100.00% <ø> (ø)
... and 9 more

... and 8 files with indirect coverage changes