fix: load rules by Include, report the blocking rule, and run the CRS tests

[raffaelschneider]

Closes #7.

Three problems, the third of which is why the first two went unnoticed.

Rule files were concatenated, which broke CRS data paths

load_rules read every --rules glob match and spliced the text together. That loses the one thing the engine needs to resolve @pmFromFile/@ipMatchFromFile paths and nested Includes: which file a directive came from. Those paths are relative to their own rule file, so a concatenated string resolved them against the process's working directory.

Same rule set, same engine version, two ways of handing it over:

from_file / Include -> OK, 703 rules
concatenated text   -> ERROR: RuleFileLoad { path: "scanners-user-agents.data", NotFound }

Stock CRS references scanners-user-agents.data among others, so the command in the README failed at startup unless it happened to be run from /etc/modsecurity/crs/rules.

The patterns are still resolved here — a bad path is still reported against the pattern that produced it, and the file count is still available for logging — but the engine is now handed quoted absolute Include directives and does the reading itself. Quoted, so a path containing spaces stays one argument.

A block reported the wrong rule

X-WAF-Rule is built from the first reported id, and the ids came from matched_rules() — every rule that matched, including CRS setup actions and chain starters whose chain never completed. Under stock CRS:

matched_rules().first()  = Some("900990")   <- what X-WAF-Rule reported
intervention.rule_ids    = ["920100"]       <- the rule that actually blocked

So whoever was debugging a block got a CRS setup rule. Ids now come from Intervention::rule_ids, and X-WAF-Message carries the rule's own msg rather than the constant "Blocked by ZentinelSec".

The CRS tests never ran, and could not have failed if they had

Three separate reasons, each sufficient on its own:

• They returned early when test-rules/crs was absent, and CI never fetched it — so they reported green as skips.
• The assertion was vacuous: assert!(blocked || !rule_ids.is_empty()), where rule_ids came from matched_rules(), which under stock CRS always contains the 901xxx setup rules. It held no matter what the engine did.
• The fixture loaded five hand-picked rule files, omitting REQUEST-920-PROTOCOL-ENFORCEMENT.conf — the file containing the rule that denies every request.

They now load the full rule set through ZentinelSecEngine itself, rather than a separately built engine that could load it differently; fail loudly with fetch instructions when the checkout is missing (ZENTINELSEC_SKIP_CRS_TESTS opts out locally, CI must not); and assert on which rules fire. CI fetches CRS.

Two tests are ignored on purpose

crs_does_not_block_ordinary_traffic and crs_does_not_block_an_ordinary_xml_post fail against zentinel-modsec 0.3.0, where CRS 920100 denies every request:

root: ordinary traffic must not be blocked, but rule(s) ["920100", "920100"] fired

That is the defect fixed by zentinelproxy/zentinel-modsec#30, so these are #[ignore]d with that reason recorded in the attribute. They are the acceptance criteria for the dependency bump — remove the attribute when it lands and they should pass. (The duplicated id in that output is also fixed there.)

I would rather leave them present-and-ignored than delete them: they are the tests whose absence let a 100%-block-rate defect ship.

Verification

• 20 tests pass, 0 fail, 2 ignored as above.
• cargo clippy --workspace --all-targets -- -D warnings clean.
• cargo fmt --all --check clean.
• Adds ZentinelSecEngine::rule_count and ::modsec so tests can exercise the rules the agent actually loaded.