feat!: remove Extra members from spans and transactions

[jamescrosswell]

Warning

Don't merge - need to work out what to do with Scopes and Events first... interrogating colleagues to try to work this out.

Removes Extra/SetExtra from SentrySpan, SentryTransaction, TransactionTracer, SpanTracer (and NoOpSpan). These were aliases over the same store as Data.

To get there, ISpanData and IEventLike no longer inherit IHasExtra, which also drops it from ISpan, ITransactionData and ITransactionTracer. Internal callers (HTTP/GraphQL handlers, ASP.NET Core middleware, EF/SQL listeners, OpenTelemetry span processor) now use Data/SetData.

Open questions for review

• Scope and SentryEvent still implement IHasExtra (now declared directly), with no Data. An event's extra is a separate protocol field from span/trace data, and it was never marked obsolete, so this PR leaves it alone. The result is a bit lopsided: IEventLike no longer exposes extras at all. Worth deciding whether that's the shape we want for v7, or whether this should wait for Attributes (as the issue suggests) and land with an analyzer/code fix.
• Scope.Apply(IEventLike) now type-switches: IHasExtra targets get extras as before, IHasData targets (transactions) get them as Data. That preserves today's behaviour of scope extras ending up in trace data, but it's the ugliest part of the change. Dropping the IHasData branch would stop scope extras reaching transactions.

Closes #4640

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (version7@8d4f28b). Learn more about missing BASE report.

Additional details and impacted files

@@             Coverage Diff             @@
##             version7    #5589   +/-   ##
===========================================
  Coverage            ?   74.80%           
===========================================
  Files               ?      515           
  Lines               ?    18913           
  Branches            ?     3698           
===========================================
  Hits                ?    14147           
  Misses              ?     3887           
  Partials            ?      879           

☔ View full report in Codecov by Harness.
📢 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.

[jamescrosswell]

This is a bit ugly... note the two separate cases that have to be considered now:

1. case IHasExtra hasExtra
2. case IHasData hasData

Reason

Spans and transactions: all have IHasData now... including ISpan, ISpanData, ITransactionData, ITransactionTracer, SentrySpan, SentryTransaction, SpanTracer and TransactionTracer... and IEventLike itself has IHasExtra Those types already had IHasData before this change. Their Extra was only an alias that read and wrote the same store as Data, so removing there is trivial.

Scope and SentryEvent: still IHasExtra... no IHasData.

Solutions

Ultimately we should be removing Extras from the Scope and SentryEvent as well. These should be replaced by Scope.Attributes and I assume Event.Attributes but Event.Attributes is nowhere on the horizon so we can't do that yet.

For the time being, this PR simply removes Extra from Spans and Transactions... which I have to say is pretty confusing. It leaves us with multiple disparate APIs:

Type	Interface
Span	IHasData
Transaction	IHasData
SentryEvent	IHasExtra
Scope	IHasExtra
Logs	Attributes
Metrics	Attributes

Honestly I think we're better off leaving IHasExtra on the the v1 Spans/Transactios so that at least there's consistency across everything except Logs and Metrics if we do that.

The other option would be to try to migrate SentryEvent and Scope to IHasData... it's kind of throw away work for us, since we'll eventually be deprecating Data as well (in favour of attributes) and it's just annoying churn for our SDK users (we'd be breaking their code twice in two releases, instead of once in one release).

[jamescrosswell]

Closing for now. See https://github.com/getsentry/sentry-dotnet/pull/5589/changes#r4032951473.

We can pick this up once we have Event.Attributes... that way we can move everything to Attributes rather than moving piecemeal to Data and then throwing all that away and moving to attributes.