Use semantic convention constants

[fractalwrench]

Goal

Replaces existing OTel semantic convention keys with the constants defined in the semantic convention dependency.

Note: as part of this I noticed that os.model.identifier and os.model.name were mistakenly set as a resource value - they should have been prefixed with device. I've chosen to fix this as I believe it will only affect OTel export & doesn't need changes on our backend.

Testing

Relied on existing test coverage.

[codecov]

Codecov Report

Attention: Patch coverage is 88.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 80.91%. Comparing base (d194ec6) to head (9ff6570).

❗ Current head 9ff6570 differs from pull request most recent head 45771b0

Please upload reports for the commit 45771b0 to get more accurate results.

Additional details and impacted files

@@                     Coverage Diff                      @@
##           use-semantic-conventions     #964      +/-   ##
============================================================
- Coverage                     80.91%   80.91%   -0.01%     
============================================================
  Files                           445      443       -2     
  Lines                         11827    11790      -37     
  Branches                       1806     1802       -4     
============================================================
- Hits                           9570     9540      -30     
+ Misses                         1462     1459       -3     
+ Partials                        795      791       -4     

Files	Coverage Δ
...droid/embracesdk/arch/destination/LogWriterImpl.kt	95.23% <100.00%> (ø)
...droid/embracesdk/internal/spans/EmbraceSpanImpl.kt	86.71% <100.00%> (ø)
...acesdk/opentelemetry/OpenTelemetryConfiguration.kt	96.77% <100.00%> (ø)
...roid/embracesdk/internal/logs/EmbraceLogService.kt	94.69% <80.00%> (ø)
...id/embracesdk/capture/crash/CrashDataSourceImpl.kt	90.32% <71.42%> (-1.21%)	⬇️

... and 13 files with indirect coverage changes

[bidetofevil]

LGTM

[bidetofevil]

Oops! Yeah, those keys are not used by us and in fact the resource object isn't even sent to our backend via the envelope. We probably should though - the resource object in the payload envelope should be a superset of this.

The reason this wasn't done was because the the attribute naming. Our backend doesn't like the . in the key names, so we never merged the two. There's an outstanding item to resolve this that we were going to do after we shipped our first version.... which is now.

More details about this here: https://www.notion.so/embraceio/How-do-we-name-payload-envelope-fields-that-are-also-OTel-attributes-and-resources-given-the-conflic-4e8bc1ea3a4c457c9243774ada475c90?pvs=4

[bidetofevil]

LGTM