feat(perf-detectors): Set default enabled state of perf Detectors based on configuration

[kcons]

Not all Performance Detectors should be enabled at creation time.
For some, it depends on the platform.
This reuses existing configs to ensure newly created performance Detector state matches the legacy behavior.

[saponifi3d]

i think we should re-think about how we're handling these to reduce the complexity in processing. Rather than us having to worry about "what detectors do we need to execute?" while executing, and instead have that filtering before the evaluation phase.

[saponifi3d]

nit: the method name makes me think it'd accept a wfe type and filter accordingly.

[kcons]

agreed, this is a name that mostly makes sense in a different context, but not here. will rename.

[saponifi3d]

i wonder how related these methods are to processing detectors, is there a new directory of file that we should make? should these live in models/detector.py since it's related to fetching? 🤔

[kcons]

I think they should probably live with performance detectors, near definitions of their Detector-based stuff. .

[saponifi3d]

should these detectors just be disabled instead? i worry that we're starting to filter / overload how we're selecting what's evaluated -- this is adding quite a bit of complexity to my mental model of how we evaluate detectors.

[kcons]

key context here:
This is replicating the behavior in

sentry/src/sentry/issue_detection/detectors/disable_detectors.py

Line 27 in ea4c577

def set_default_disabled_detectors(project: Project) -> None:

and to an extent the baked in defaults of enabled state for Performance detectors that are part of the default projectoption config.

In the case that it is "default detectors aren't necessarily enabled by default" it seems like it'd be something we'd annotate onto Detector definitions probably along with some other defaulting info. We don't have a great place to put that at the moment, so I figured we'd start by just using the primary source of the data now for guaranteed consistency and a clear data path.

This default enabled or not thing is complicated by the "oh, some languages (platforms) really shouldn't have this" which is a sort of manually tacked on thing.

I think ideal structure for this whole defaulting setup might be somehing like:

for detector_spec in  DetectorSpecs.all(defaulted=True):
       initial_config, default_enabled = spec.default_state_fn(project)
       _ensure_detector(detector_spec.slug, initial_config, default_enabled)

although it seems entirely possible that the rules for what is there by default are more nuanced than it makes sense for us to try to shoehorn into something simple.

[saponifi3d]

i lied -- looks like this is doing it in the ensure / before, and i was just confused with all the processors/detectors.py code living here.

I think we should split out the majority of the ensure_* methods here in another pr, that would really reduce complexity and help out with keeping everything a bit more organized.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}