feat(tracer): add more convenience methods for enterings spans

[bantonsson]

Changes

This adds 3 convenience methods to the Tracer trait that allows users to create, start, and enter a scope with an active Span with parent contexts and based on a SpanBuilder.

Right now, the easiest way to enter a Span is to use the convenience method on the tracer that only takes a name and then add tags to the span afterwards. This is problematic in the sense that samplers and processors that take attributes into account will not see these attributes at creation time.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.9%. Comparing base (53c9f47) to head (f2faaec).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3251     +/-   ##
=======================================
+ Coverage   80.8%   80.9%   +0.1%     
=======================================
  Files        129     129             
  Lines      23203   23372    +169     
=======================================
+ Hits       18750   18919    +169     
  Misses      4453    4453             

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cijothomas]

Looks good. lets add a changelog.md entry before merge.

[cijothomas]

based on our benchmarks (https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/benches/span.rs#L71) the in_span is not the most performant way to span creation/activation.

Not opposed to this change, just noting the perf implications. Maybe we can improve the implementation to make it better, and/or warn users about perf implication in the doc in follow ups.

[bantonsson]

I'll take a look at the benchmarks and extend them with versions for these variants.

[bantonsson]

So the benchmarks are really comparing apples and oranges. Do we want comparable numbers or what are we trying to measure in the benchmarks? Yes, if you don't attach a Span to the Context it will be faster than attaching a Span to the Context. If you don't set an Attribute on a Span it will always be faster than setting an Attribute on a Span.

The bigger question is what type of API do we want to have here. Should we have a method that maybe attaches the Span to the Context and gives you a ref to the Span instead of the Context? This would mean that Context::current() would return a Context that doesn't have this Span attached. This feels weird and I can't really see why you would want that.