Flesh out synchronization of EmbraceSpan functionality

[bidetofevil]

Goal

Flesh out synchronization of the wrapper EmbraceSpan given that we know the operations in the SdkSpan are synchronized already.

[bidetofevil]

• Expose OTel Tracer API through Embrace SDK #911
• Flesh out synchronization of EmbraceSpan functionality #938 👈
• Synchronize status setting of EmbSpan #944
• Implementation for Tracer, TracerBuilder, and TracerProvider OTel APIs #910
• Implementation of OTel SpanBuilder API #930
• Store and use EmbraceSpan in an OTel Context object  #925
• Propagate full parent context in EmbraceSpanBuilder #909
• Add ability to reset parent and add SpanKind to EmbraceSpanBuilder #919
• Change storage and application of start time on wrappers #918
• Refactor attribute storage in EmbraceSpan and EmbraceSpanBuilder #917
• Create Span with EmbraceSpanBuilder in SpanService #908
• Create a span with EmbraceSpanBuilder from factory #907
• Implementation for OTel Span API #906
• Add ability to rename spans that have not ended #903 : 1 other dependent PR (#867 )
• Add extension function to turn OTel Attributes into a map of strings #902
• Record exception happening during a span as a SpanEvent #897
• Move EmbraceSerializer to InitModule #896
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on Graphite

[bidetofevil]

This is the main change - If a newly started span is not actually recording, it means the underlying span is a non-recording one or has already been stopped (i.e. the wrapping span builder has already created the span and stopped it on another thread), so we fail the invocation of this wrapper call, first-writer-wins style. We do the same for stop()

[bidetofevil]

Changing the code to check whether the associated span is recording before returning that a start call has succeeded means that if I used a real Tracer, it would find that the parent I had set is fake (and therefore the Context object isn't populated), so it'll fail.

Since the goal for this is testing the unit, I'm going to use a fake in here instead so the implementation detail of another object doesn't affect the results of this test.

[fractalwrench]

LGTM

[codecov]

Codecov Report

Attention: Patch coverage is 84.44444% with 7 lines in your changes missing coverage. Please review.

Project coverage is 80.91%. Comparing base (269801f) to head (1f179b3).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #938      +/-   ##
==========================================
- Coverage   80.94%   80.91%   -0.03%     
==========================================
  Files         444      444              
  Lines       11800    11802       +2     
  Branches     1802     1802              
==========================================
- Hits         9551     9550       -1     
- Misses       1456     1458       +2     
- Partials      793      794       +1     

Files	Coverage Δ
...droid/embracesdk/internal/spans/EmbraceSpanImpl.kt	86.71% <84.44%> (-1.38%)	⬇️

... and 1 file with indirect coverage changes