feat(core, matchers): Telemetry types & discovery mode

[Minosity-VR]

What does this PR do?

Warning

This PR changes the core matcher interface. It is a breaking change for any code calling threatest as a library and using the matchers directly.

It is not a breaking change for CLI users. Commands and scenario files stay identical. The json output gained an additional json field

Enhancements:

• Create a unified object to expand the matchers to new telemetry types (logs, events...)
• Add new datadog matchers for agent events and logs
• Add a discovery mode that polls telemetry and return the contents (not just a boolean). Query used for the discovery controllable by the user, with a default provided

Motivation

• Discovery mode: when using in purple team exercises, attackers often detonate TTPs without knowing exactly what will be triggered. With this feature, they can tell the blue teams what telemetry they found, if they were seen, etc.
• More telemetry types: alerts are often the 'end' of the processing pipeline, but earlier resources are useful for the user too. Tried to stay generic and stick to OpenTelemetry's Events format so almost any matcher can be added

Checklist

Agent events discovery:
Using some internal stratus-red-team technique (I will try to opensource it at some point), I launched a k8s pod that starts a xmrig cryptominer. Didn't want to relaunch it all the time so I 'cheated' and use a local scenario launching a benign command, but fetching the events as if it was a normal scenario:

Logs and signals discovery: launched the aws.defense-evasion.dns-delete-logs stratus TTP:

(note: this screenshot is not from the latest commit, now the objects appear under their own assertion category instead of being mixed up at the end)

[NathanaeldeLaChesnais]

Not sure if this should be hard coded at this level. In particular, don't we want the lookbackWindow to be editable by the caller and to be shared among all modules?

[Minosity-VR]

The caller can control the time range in library mode (WithTimeRange option). I didn't expose it in the scenario yaml/CLI because I didn't want to overload it, but we could.

And for the shared value, I think it's better to control it per matcher: depending of the expected amount of resources, the processing time and other factors, it could make sense to have a longer search window for signals than logs for instance

Good catch though, because I missed it during the refactor: I changed the default timewindow of datadog signals from 1h to 15min. Will revert to 1h