analyze: enable sigs consuming sigs

[NDStrahilevitz]

1. Explain what the PR does

df567eb fix(analyze): enable sigs consuming sigs
ad56d06 fix(findings): clone properties before rewriting
84ceba7 chore: move finding event conversion to a package
3b32997 chore: decouple sig init from init

df567eb fix(analyze): enable sigs consuming sigs

Signatures consuming other signatures relied on the single binary
reprocessing finding events into the pipeline. This did not occur in
analyze mode. Introduce that mechanism so that it now works.

Co-authored-by: Asaf Eitani <[email protected]>

84ceba7 chore: move finding event conversion to a package

Opportunistic refactor. Logic does not relate to eBPF and does relate to
event data. Also allows importing this logic without importing eBPF
related code.

3b32997 chore: decouple sig init from init

This allows initializing signature to event data without importing eBPF
initialization logic, which require specific compilation tags.

Co-authored-by: Asaf Eitani <[email protected]>

2. Explain how to test it

Currently we have internal tests for it. Confirmed it was working using those.

3. Other comments

Resolve #4326

Analyze is emitting warnings due to sig of sigs loading lack.

[geyslan]

I tested it again since I noticed you removed the recursive loading what made the initial behaviour stands. For each selected event that is a signature, analyze emits an error:

{"level":"error","ts":1727381548.0349305,"msg":"Failed to load event dependency","event":"internal_sig"}
...

[NDStrahilevitz]

I tested it again since I noticed you removed the recursive loading what made the initial behaviour stands. For each selected event that is a signature, analyze emits an error:

{"level":"error","ts":1727381548.0349305,"msg":"Failed to load event dependency","event":"internal_sig"}
...

Weird, I haven't seen it in my test. Maybe because I checked with grep, let me see.

[NDStrahilevitz]

Manually tested on both tracee-rules and analyze.
@geyslan please review at your pace.

[geyslan]

LGTM

[NDStrahilevitz]

Waiting for a final review by @geyslan before merging.
I've made changes such that the feedback concern is handled entirely in the engine context and not in analyze. Later on, the feedback should be included into derived events and fed into the processing stage.
Further, i've resolved some crash issues that were introduced in initial versions of the PR, a concurrency safety issue in finding->event conversion, and made sure that analyze mode remains as deterministic as it was before (it is msotly deterministic in output size but not in order, which may affect output size given a signature dependent on order).