fix(txnames): Revert high threshold for running the clusterer

[jjbayer]

As part of https://github.com/getsentry/team-ingest/issues/93, we merged #46503, to ensure we would not run the clusterer for fresh projects until they collect a high amount of unique transaction names. This was based on a suspicion that we would otherwise declare all URL transactions as sanitized prematurely.

However, we did not have any data to back up this decision, and there is no reason to impose this threshold from the algorithm's point of view: There is already the (lower) MERGE_THRESHOLD which should prevent low-quality replacement rules.

What we do know is that we've seen a decline in the number of transactions changed by clustering rules (see metric event.transaction_name_changes), which might be because we are now too strict about when we run the clusterer.

[olksdr]

lgtm!

[codecov]

Codecov Report

Merging #49087 (14ff455) into master (aaa7d66) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #49087   +/-   ##
=======================================
  Coverage   80.92%   80.92%           
=======================================
  Files        4819     4819           
  Lines      202008   202008           
  Branches    11412    11412           
=======================================
+ Hits       163467   163470    +3     
+ Misses      38287    38284    -3     
  Partials      254      254           

Impacted Files	Coverage Δ
src/sentry/ingest/transaction_clusterer/tasks.py	97.56% <100.00%> (ø)

... and 3 files with indirect coverage changes

[iker-barriocanal]

to ensure we would not run the clusterer for fresh projects until they collect a high amount of unique transaction names. This was based on a suspicion that we would otherwise declare all URL transactions as sanitized prematurely.

At that time, I played around with a subset of data of different sizes and different merge thresholds, and the ratio definitely influences the amount and quality of the rules. Given it's hard to get rid of a rule once generated, we decided to play safe here. This conclusion was taken from a small subset of data that isn't representative of the algorithm, but we should consider the impact on the quality.

What we do know is that we've seen a decline in the number of transactions [...] which might be because we are now too strict about when we run the clusterer.

It could also be because rules were disappearing over time, so fewer transactions were sanitized. Once we bump the rules properly, this could no longer be a problem.

I'm approving the PR because I don't have data to tell if this is a good or wrong decision, but we should monitor it.

[jjbayer]

It could also be because rules were disappearing over time, so fewer transactions were sanitized. Once we bump the rules properly, this could no longer be a problem.

That was the immediate cause, but shouldn't the cluster have immediately rediscovered those rules after they expired?

I'm approving the PR because I don't have data to tell if this is a good or wrong decision, but we should monitor it.

Thanks, I added some more metrics in recent days, will add them to the dashboard and configure some alerts.