Clean up code relating to scope/event `transaction` value

[lobsterkatie]

Long ago, Sentry events had the idea of a culprit, which was a string approximately meaning, "the context in which this error happened." A number of years ago, a(n only-partially-successful) attempt was made to replace culprit with transaction, which remained a string with the same basic meaning. Then we got into the APM business, and began to use the word transaction to refer to the root span of a tracing span tree, while still retaining it in some places as a string meaning "the name of the active (tracing-type) transaction," or keeping its original meaning if tracing isn't enabled. This caused confusion, so we changed some APIs to refer to the string as transactionName, so that transaction could mean "root span object." We've also made various changes throughout the years (both recently and in the more distant past) to improve our ability to figure out the right transaction value.

So where are we now? Kind of in a mess, unfortunately.

• Scope.setTransactionName and Scope.getTransaction.setName change two different, independent pieces of data.

• In the requestData module in @sentry/utils we have extractTransaction and extractPathForTransaction, which do slightly different things and which are called by both addRequestDataToEvent (called for both errors and transactions) and addRequestDataToTransaction (called only for transactions, but not in every SDK). extractPathForTransaction is also called directly by other parts of the SDK, at various points of the transaction lifecycle. This makes it almost prohibitively hard to make changes, because reasoning about the effects of those changes across all of the various code paths is so difficult.

• An event's transaction value can come from at least six different places: event creation, from the scope, from the addRequestDataToEvent function called by event processors in various SDKs, from the addRequestDataToTransaction function called by our Express tracing handler, from an error event's stackframes, and soon from the new RequestData integration. Which (and how many) of these various options apply depends on the type of the event, which SDK is running, the settings passed to our Express request handler, and possibly other things I'm forgetting. This means, among other things, that an error event and its associated transaction event might have different transaction values. (See screenshot below.)

• Events also have a transaction tag, which comes exclusively from the name of the active Transaction object, but which gets overwritten by the transaction value during ingest, regardless of whether it's set or what it's set to.

• We still have a Transaction integration dating from the pre-APM-attempt-to-replace-culprit-with-transaction days, which uses stackframes to find an event's transaction (with the result that people end up with minified function names as their transaction values).

Before v8, let's take a hard look at this.

Related issues:
#5768
#5660

---

Example of second point above: