feat(seer grouping): Call Seer before creating a new group

[lobsterkatie]

This uses the helpers added in #70999 to - depending on the state of the projects:similarity-embeddings-metadata and projects:similarity-embeddings-grouping flags - decide whether we should call Seer before creating a new group, make the API call if so, and then store the results and/or use them to actually prevent new group creation in favor of using an existing similar issue. The behavior is as follows:

| metadata  | grouping | call  | metadata in | metadata in | use Seer-matched |
|   flag    |  flag    | Seer? |   event?    |   group?    |  group, if any?  |
|-----------|----------|-------|-------------|-------------|------------------|
| off       | off      | no    | -           | -           | -                |
| on        | off      | yes   | yes *       | yes         | no               |
| on or off | on       | yes   | yes *       | only if new | yes              |

* For now, the only event with the data will be the event which triggers the Seer 
call, not subsequent events with that hash. In the long run we will probably need
to store the data on the `GroupHash` record itself. 
See https://github.com/getsentry/sentry/issues/70454.

This should be enough for us to run a POC on S4S and measure the effect on grouping.

[vartec]

Wouldn't we want to keep that for debugging even after testing phase?

[lobsterkatie]

We might end up keeping it, but the current plan is to take it out eventually. For debugging purposes, we have the same information on the event hopefully added to the corresponding GroupHash record. (See #70454.)

[vartec]

purely opinion based, so entirely up to you, but I find just regular ifs more readable than using conditional expressions multiple times.

Suggested change

	is_new = False if seer_matched_group else True
	is_regression = (
	False
	if is_new
	else _process_existing_aggregate(
	# If `seer_matched_group` were `None`, `is_new` would be true and we
	# wouldn't be here
	group=NonNone(seer_matched_group),
	event=event,
	incoming_group_values=group_creation_kwargs,
	release=release,
	)
	)
	if is_new := not seer_matched_group:
	is_regression = False
	outcome = "new_group"
	else:
	is_regression = _process_existing_aggregate(
	# If `seer_matched_group` were `None`, `is_new` would be true and we
	# wouldn't be here
	group=NonNone(seer_matched_group),
	event=event,
	incoming_group_values=group_creation_kwargs,
	release=release,
	)
	outcome = "seer_match"

and below...

                span.set_tag("outcome", outcome)
                metric_tags["outcome"] = outcome

[lobsterkatie]

It's true, I do love a good ternary. 🙂 I do sometimes get the sense that they're a little more idiomatic in JS/TS (which is - for better or worse - very much my first love, programming-language-wise) than in Python. Also for whatever reason it actually does make more sense to my brain. But you're right that there's a time and a place, and I do probably lean into it a little hard sometimes.

I'm going to leave it as is for now. [UPDATE: Partially true - I did change to is_new = not seer_matched_group.] It works, and there's lots more to do, but I do take the overall point.

(FWIW, the structure of _save_aggregate_new is different enough that when I port this there, I think I am going to have to structure it more with ifs than with ternaries.)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.90%. Comparing base (d6767ca) to head (a60dc00).
Report is 2 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #71026       +/-   ##
===========================================
+ Coverage   56.77%   77.90%   +21.12%     
===========================================
  Files        6516     6525        +9     
  Lines      290322   290617      +295     
  Branches    50236    50286       +50     
===========================================
+ Hits       164834   226399    +61565     
+ Misses     120747    57971    -62776     
- Partials     4741     6247     +1506     

see 1955 files with indirect coverage changes

[jangjodi]

do we know what exception types we're catching here? or is this meant to be a generic catch so that we don't break anything and lose events?

[lobsterkatie]

Much more the latter. Any reasonably-anticipatable errors in that logic are caught before they bubble up this high, but the last thing I want to do is break ingestion, so it seemed wise to try-catch it just in case. (But yeah, I can add a comment, because it's a reasonable question. [UPDATE: Done.])