ref: Remove SentryTransaction from public API.

[brustolin]

📜 Description

Created a SentrySpan protocol to expose in the SDK and removed SentryTransaction from the public API.

💡 Motivation and Context

The user should not have access to SentryTransaction.

💚 How did you test it?

Unit tests

📝 Checklist

• I reviewed the submitted code
• I added tests to verify the changes
• I updated the CHANGELOG if needed
• I updated the docs if needed
• Review from the native team if needed
• No breaking changes

🔮 Next steps

TBD

[brustolin]

This is a suggestion based on our last meeting about Performance API and the open discussion #936.

Thoughts?

[marandaneto]

Spans don't have a name, only a Transaction

[brustolin]

This is a suggestion based on the openTelemetry definition.
Removing the name of span creates a new "problem", startTransaction requires a name as a property, but the return is a Span, and the user cannot check the name again.
Lets say the user has a callback to define sampling, and it uses the transaction name in the decision process.

[marandaneto]

wondering if this is the API design on Cocoa, because on Java we don't rely on the transaction object to do sampling, see docs https://docs.sentry.io/platforms/java/configuration/sampling/

during the call, the discussion was more around, the SentryTransaction class still exists, but we'd expose only Span, which means, internally SentryTransaction still is used (sampling would be a case I guess), the user wouldn't only manipulate it directly, this would reduce the amount of breaking changes.

[brustolin]

I did not work with sampling yet, but I really thought the user would have access to the span for decision making, it make more sense to me knowing what I'm sampling to decide.
Still find it odd to have a parameter and then don't have a way to access the value used.
Well, let's leave this discussion to the future if some user case appears, for now I will remove the name field.

[marandaneto]

@brustolin this discussion already came up, getsentry/develop#243 we do head-based sampling, so we won't likely have the full information, anyway, this is a known limitation right now, you've been tagged to that issue btw.

[marandaneto]

@bruno-garcia we had 2 options during the call, one was just hiding SentryTransaction but keeping it as it is, creating it, and adding spans to it, the return type would be ISpan though, so hidden in the Public API point of view.

the other one would be creating a SentryTransaction only at the end, as written in your code snippet, this one would require more changes (adding a root span boolean to the span? adding a name to the span? do we get start timestamp from root span? etc...).

We didn't decide on the 1st or 2nd, but actually, to Draft a PR and see what makes more sense, @maciejwalkowiak said that the 1st option would be easier/faster.

[maciejwalkowiak]

I am reconsidering. Option 1st is also not trivial.

[brustolin]

This PR offers a third option. I had created a Tracer class (inspired in openTelemetry) that implements Span, is thread-safe, and responsible to handle spans creation. The Tracer finish has the approach mentioned by bruno.

[marandaneto]

which is fine but this would require a proposal & approval API (so this PR would be a Draft rather than ready to be reviewed/merged), because it differs quite a lot from other SDKs, not telling is a bad idea, but trying to align with other folks first (whom originally designed the current API), the 2 options discussed during the meeting still kept the same public API but not exposing the Transaction object.

maybe @rhcarvalho has something to add.

[bruno-garcia]

We're trying to propose a new way that will be taken by the other SDKs.
The complexity of the refactor plays a role but can't be the main driver. We need to sort out some major concerns (which this PR addresses).

Lets review this on a call collect the points so we can move forward

[marandaneto]

similar to https://github.com/getsentry/sentry-cocoa/pull/950/files#r576791171

[marandaneto]

@brustolin could you pull master and feat/performance-monitoring into this branch, feels like a lot of changes are unrelated to this PR and hard to review (73 files)