ref(spans): Detect performance issues directly in segments consumer

[jan-auer]

Creates a single step in the segments consumer that detects performance issues
and produces occurrences to the issue platform. This function no longer relies
on EventManager, but it does create an event payload internally.

Issue detectors have quite a few places where they read directly from the event
data dict. We're keeping this for now, so that issue detectors can be refactored
at a later point when issue detection in the transaction pipeline has been
disabled.

Changes:

• Call detect_performance_issues directly in the consumer.
• Simplify the function that creates the shim event dict for issue detectors.
• Move topological sorting of spans into the performance detection module.
• Inline producing issue occurrences into the detection step in the consumer.
  This will become a single side-effect step in the later platform.

Ref https://github.com/getsentry/streaming-planning/issues/67

[jan-auer]

We no longer need the is_standalone_spans flag here since we don't call this from the consumer anymore.

[jan-auer]

Please have a look at what this function does. It now:

• Creates an event payload with as many fields as possible populated.
• Runs that event payload through issue detectors.
• Trims the event payload to a smaller subset.
• Creates an issue occurrence and sends it into the issue platform.

I would suggest to keep this for now, until we've disabled issue detection in the old transactions pipeline. That will make it easier for the performance/issues teams to refactor issue detectors on span payloads and create this flow instead:

• Run the segment's spans directly through issue detectors. Internally, detectors pull top-level attributes (like "browser.name") from the segment span.
• Create a minimal event payload for the issue occurrence
• Send it to the issue platform

[jan-auer]

Issue detectors don't read the _precise timestamps from standalone spans yet, since Relay doesn't produce them for embedded spans in transaction events.

1. We can inject the _precise fields into Event spans in Relay so that we can update detectors and get rid of this modification here.
2. Alternatively, we always create timestamp and start_timestamp and operate on those in the entire pipeline + we pull the attributes from there in EAP ingest.

@mjq Is there already a definition of how spans should look wrt this?

[jan-auer]

This was moved from the old spans consumer. I'd like to leave it to the owners of performance issue detection whether detectors should be updated or this code remains.

The only change here was that we prevent modifying the original payload.

[codecov]

Codecov Report

Attention: Patch coverage is 97.22222% with 2 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...sentry/spans/consumers/process_segments/message.py	92.30%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #86595      +/-   ##
==========================================
- Coverage   87.79%   87.79%   -0.01%     
==========================================
  Files        9771     9771              
  Lines      553386   553369      -17     
  Branches    21640    21640              
==========================================
- Hits       485864   485809      -55     
- Misses      67151    67189      +38     
  Partials      371      371              

[jan-auer]

This sends the trimmed down event payload along with the is_buffered_spans flag into the issue platform. @mrduncan we can further trim down the payload based on what is needed for the created issues to work.

Note that the issues are still created with PerformanceStreamedSpansGroupTypeExperimental - I didn't check what exactly this type does different. I just noticed that when I remove it, at least in my test there are no more occurrences created.