Allow detectors to customize cleaning logic

[rosecodym]

Description:

We have identified some cases in which the results "cleaning" logic (the logic that eliminates superfluous results) should not run. In order to allow this, we need to expose the cleaning logic to the engine. This PR does so by doing these things:

• Extending the Detector interface with a pair of methods to control cleaning logic
  • This is done via the creation of a new interface that is embedded
• Creating a default implementation of this interface that can be embedded in detectors that don't need to customize this logic
• Embedding this default implementation in every detector except aws and awssessionkey
  • This represents a change of behavior for opsgenie, twilio, and razorpay, but we have determined that those detectors' previous customization of their cleaning behavior was incorrect and should be removed
• Invoking this new cleaning logic from the engine rather than individual detectors

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[rgmz]

Nothing against this specific change, however, it feels like the number of detector-related interfaces and default implementations is getting out of hand (multi-part creds is another confusing one).

IMO, it would be cleaner ( 😎 ) to use the default CleanResults function unless the detector has a special CustomResultCleaner interface.

[rosecodym]

Nothing against this specific change, however, it feels like the number of detector-related interfaces and default implementations is getting out of hand (multi-part creds is another confusing one).

IMO, it would be cleaner ( 😎 ) to use the default CleanResults function unless the detector has a special CustomResultCleaner interface.

Heh, I will point out that when I did the false positive change that way @mcastorina suggested I instead use an embedded default logic provider (like I did here), which is why I did this. But I actually prefer that solution, so I'll take a pass at it.

@rgmz do you remember any details about that interface-smuggling related bug you found awhile ago? I want to ensure I don't trip over it again.

[mcastorina]

I'm not sure why I suggested that in the past, but I agree with @rgmz's suggestion to use interface smuggling here. I think it makes a lot of sense for detectors to have opt-in behavior for special handling, considering how many detectors we have.

[rosecodym]

#3235 is an implementation that uses interface smuggling

[rgmz]

@rgmz do you remember any details about that interface-smuggling related bug you found awhile ago? I want to ensure I don't trip over it again.

The bug was in how the nested structs / interface matching works. #2960

[rosecodym]

doing #3235 instead