remove unneeded current span functions from otel_tracer

[tsloughter]

?end_span is updated to work update the current context through
calling otel_tracer:set_current_span. In order to still return
the new SpanCtx this function was also changed to return the
SpanCtx that was passed to it.

[codecov]

Codecov Report

Merging #284 (0df1e7d) into main (700e2ea) will increase coverage by 0.04%.
The diff coverage is 40.00%.

@@            Coverage Diff             @@
##             main     #284      +/-   ##
==========================================
+ Coverage   36.55%   36.59%   +0.04%     
==========================================
  Files          45       45              
  Lines        3187     3178       -9     
==========================================
- Hits         1165     1163       -2     
+ Misses       2022     2015       -7     

Flag	Coverage Δ
api	63.20% <40.00%> (+0.75%)	⬆️
elixir	16.42% <40.00%> (+0.50%)	⬆️
erlang	36.56% <100.00%> (+0.06%)	⬆️
exporter	19.75% <ø> (ø)
sdk	78.94% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...pps/opentelemetry_api/lib/open_telemetry/tracer.ex	40.00% <0.00%> (-6.16%)	⬇️
apps/opentelemetry_api/src/otel_tracer.erl	81.81% <100.00%> (+31.81%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 700e2ea...0df1e7d. Read the comment docs.

[tsloughter]

I don't like that tracer.ex still has these functions because I don't know a better place to put functions that work on the current span. The Erlang API keeps all of those in the header macros so that there is a separation between the API working on the current process dictionary and the one working against explicit arguments.

Though I don't like that the Erlang header is otel_tracer.hrl, these aren't actually Tracer operations. They aren't really just Span operations either... Maybe there should be otel.hrl? Maybe it is better to just accept the naming not being perfect in order to not break more stuff?

[ferd]

Eh, unless there's a clear path forwards and we know where we're going, any change is just another guess that makes an actual fix's friction a bit worse?

[tsloughter]

Yea, you are right. The Elixir naming (having Span operations that work on the current span only available in Tracer) is weird enough we might want to see if we can figure out a clear path, but if not just leave it.