Always re-use discovery dates per default if the data key matches

[8R0WNI3]

What this PR does / why we need it:
Instead of hardcoding a list of finding types for which to re-use discovery dates, re-use them by default if the data key (i.e. their identity) matches. This behaviour may be adjusted per finding type (e.g. for vulnerabilities, only re-use if the package and CVE match).
Finding types can still be configured via the findings-cfg to not honour existing discovery dates at all, e.g.:

- type: finding/<type>
  reuse_discovery_date:
    enabled: true | false
    max_reuse_time: 30d

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

The discovery dates of findings are now re-used by default based on the finding's identity. This behaviour can be disabled via the findings-cfg `[].reuse_discovery_date.enabled` flag. For `sast` findings it is typically desirable to disable it because a missing SAST scan is always bound to a specific source snapshot and has no earlier discovery date in that sense.

[zkdev]

do we consider this as a breaking change from a semantical PoV?

[8R0WNI3]

do we consider this as a breaking change from a semantical PoV?

Looking at the findings types which will now also re-use the discovery dates:

• falco -> not being processed (yet)
• kyverno -> not being processed (yet)
• ghas -> we don't have any of those findings (yet)
• inventory -> should have been the desired behaviour anyways -> rather considerable as a bugfix
• malware -> always had "blocking" semantics anyways -> an earlier discovery date won't change this -> rather considerable as a bugfix
• sast -> always had "blocking" semantics anyways -> an earlier discovery date won't change this BUT a sast finding is only ever applicable to exactly one OCM artefact version, so it might always be considered as a new finding

I think for sast findings we should disable the re-use of discovery dates, so I agree we should rather consider this as breaking. Wdyt?

[ccwienk]

do we consider this as a breaking change from a semantical PoV?

I think for sast findings we should disable the re-use of discovery dates, so I agree we should rather consider this as breaking. Wdyt?

do we know whether there are other usages of sast-extension than our own (gardener)? if not, we can still mark this as breaking, but we will not need to take any precautions w.r.t. rollout.

[8R0WNI3]

do we know whether there are other usages of sast-extension than our own (gardener)?

No, there are no other (active) usages yet.

if not, we can still mark this as breaking, but we will not need to take any precautions w.r.t. rollout.

Agree, I have adjusted the release-note accordingly.