Add opt-in RSigma library backend for Sigma detection

[mostafa]

Summary

Adds an opt-in RSigma library backend for Sigma detection, selectable at runtime, while keeping Rustinel-owned normalization, logsource classification, ECS alerting, hot reload, and IOC and YARA unchanged. The built-in matcher stays the default, so existing deployments are unaffected. RSigma ships as an opt-in experimental backend: it is a new detection path that may differ in behavior from the built-in matcher.

• The rsigma-engine Cargo feature compiles the RSigma engine (rsigma-parser + rsigma-eval, v0.18) in alongside the built-in matcher; both are present in feature builds and chosen at runtime.
• Select the engine with rustinel run --sigma-engine <builtin|rsigma>, the scanner.sigma_engine config key, or EDR__SCANNER__SIGMA_ENGINE. The default is builtin. --sigma-engine rsigma parses in every build; requesting rsigma from a binary built without the feature fails fast at startup through the shared resolver with a clear "built without rsigma-engine" message.
• Zero-copy rsigma_eval::Event adapter over NormalizedEvent, so stateless detection needs no per-event JSON on the hot path.
• The RSigma loader parses with rsigma-parser and compiles into one engine per normalized logsource, reusing the existing platform and logsource load decisions so rule bucketing and skip stats match the built-in path. EvaluationResult is mapped back to Rustinel's Alert (severity, rule id, and match-detail translation gated on the existing match-debug setting).
• The public Engine API is preserved; check_event, load_rule, and stats dispatch on the selected backend, so handler, reload, and runtime are unchanged apart from threading the selection.
• The official release binaries are built with --features rsigma-engine so the flag works out of the box; the default developer build is built-in only.

Also included:

• A Detection-as-Code CI gate using timescale/rsigma-action to lint and validate the bundled Sigma rules.
• A workflow that runs the full suite under --features rsigma-engine; a parity test builds both backends in-process and asserts they agree.
• Engine-selection resolution tests: config value, EDR__SCANNER__SIGMA_ENGINE override, invalid value, rsigma with and without the feature, and CLI precedence over config.
• A Criterion benchmark documented in docs/benchmarking.md, comparing the two backends.
• Docs for engine selection in the detection guide and the CLI and configuration references, including an engine-conformance table and the experimental note.

Correlation (RSigma's stateful engine) is intentionally out of scope here and can follow as a separate opt-in feature.

Refs #85.

Test plan

• cargo test (built-in backend)
• cargo test --features rsigma-engine (both backends; the parity test compares them in-process)
• cargo clippy --all-targets -- -D clippy::all, and the same with --features rsigma-engine
• cargo fmt --all -- --check
• rustinel run --sigma-engine rsigma selects the RSigma engine; the same flag on a non-feature build errors at startup
• cargo bench --bench sigma_backend with and without --features rsigma-engine

Performance

On a trivial ruleset the built-in matcher is marginally faster; on a ~2,000-rule corpus the RSigma backend is about 1.4x faster. Details in docs/benchmarking.md.

[Karib0u]

Thanks for the spike. I reviewed it and the direction looks good.

This validates the approach from #85: RSigma is integrated as an optional stateless backend, Rustinel keeps normalization/logsource routing/ECS output/hot reload ownership, and the full rsigma-runtime is not introduced.

I think we should include rsigma-engine in the official release binaries. The default remains builtin, so existing deployments are unchanged, but users can try --sigma-engine rsigma without rebuilding from source. That should give us much better real-world feedback on parity, diagnostics, and performance.

Since this means RSigma becomes a shipped opt-in backend, I suggest documenting it clearly as experimental for now. The important point is not that it is a third-party dependency, since we already ship dependencies, but that it is a new detection backend and may have behavior differences from the built-in matcher.

Before merging, I would do a small finalization pass:

• Add explicit tests for engine selection resolution:
  • config value
  • env override (EDR__SCANNER__SIGMA_ENGINE)
  • invalid engine value
  • requesting rsigma without the feature
  • CLI override precedence over config
• Clarify non-feature CLI behavior. Ideally --sigma-engine rsigma should parse in all builds, then fail through the same startup resolver as config/env with the clear “built without rsigma-engine” message.
• Keep release binaries built with --features rsigma-engine, but document RSigma as an opt-in experimental backend for now.
• Remove BENCHMARK.md as a top-level file, or move/merge that content into docs/benchmarking.md so benchmarking docs stay in one place.

[mostafa]

Thanks for the review. Finalization pass pushed, mapping to your points:

• Engine-selection resolution tests: added unit tests over SigmaEngineKind::parse/resolve (config value, invalid value, CLI override precedence, and rsigma requested with and without the feature) plus config tests for the builtin default and the EDR__SCANNER__SIGMA_ENGINE override. (db9b79c, 49edbf5)
• Non-feature CLI behavior: --sigma-engine rsigma now parses in every build and fails through the same startup resolver as the config and env value, with the clear "built without rsigma-engine" message, instead of being rejected by the argument parser. (db9b79c)
• Release binaries keep --features rsigma-engine, and RSigma is now documented as an opt-in experimental backend in the detection guide, next to the engine-conformance table. (88f1529)
• Removed the top-level BENCHMARK.md and moved its content into docs/benchmarking.md as a dedicated Sigma-engine micro-benchmark section, so benchmarking docs live in one place. (7de1c00)

cargo test, clippy, and fmt are green in both the default and --features rsigma-engine configurations.