Add performance audit document for ModSecurity v3

[Easton97-Jens]

Motivation

Provide a concise but technically grounded performance audit of libmodsecurity v3 to document execution hotspots, quantify resource usage, and identify optimization opportunities for real-world CRS-style deployments.

This audit was created with assistance from AI tools:

• ChatGPT for structuring, summarization, and explanation
• Codex for code-path reasoning and performance-oriented analysis

---

Description

This issue proposes adding a new documentation file:

doc/performance_audit_modsecurity_2026-04-03.md and further documentation file

The document provides a deep technical performance evaluation of libmodsecurity v3, including:

Key findings

• Primary cost driver: rule execution fanout scaling roughly with R × V × T × O
• Dominant bottleneck: regex (@rx) evaluation, especially under transformation-heavy pipelines
• Systemic risk: tail-latency degradation under high concurrency due to combined CPU + I/O pressure
• High-impact optimization: regex call reduction (15–35% CPU improvement, 10–25% latency reduction)

Technical coverage

• Request lifecycle and execution model
• Rule evaluation hot paths (RulesSet::evaluate, RuleWithOperator::evaluate)
• Parsing overhead (URL-encoded, JSON, XML, multipart)
• Regex behavior, backtracking risks, and JIT considerations
• Memory model (80 KB – 1.5 MB typical, up to 8 MB for multipart peaks)
• Audit logging and I/O impact (0.5 KB – 100+ KB per request depending on mode)
• Concurrency scaling behavior and saturation points (typically 16–64 workers)

Performance characteristics

• CPU dominated by regex + transformations (up to 70%)
• Memory shows burst-sensitive scaling under large payloads
• I/O becomes critical under full audit logging

Optimization priorities

• Regex prefiltering and scope reduction (P0)
• Async/selective audit logging (P0)
• Transformation pipeline reduction (P1)
• Multipart streaming improvements (P1)

Overall assessment

• Performance score: ~5.3 / 10 (security-effective but resource-intensive without tuning)

---

Reference

Related PR:
Easton97-Jens#41