Logging testing

[jcchavezs]

Description

Over the last months we have been receiving issues from users that involve log output in different parts of the library and connectors. For example:

• Double break line when writing error logs coraza-caddy#87
• Missing hostname in WAF logs coraza-caddy#75
• Duplicate modsecurity fields's in caddy logs's coraza-caddy#32
• Logging into JSON coraza-caddy#20
• Unable to read variables in the audit/error.log #847
• MatchedRules filled by rules without log directive #839
• Coraza isn't matching a single rule multiple times like modsecurity does #760

While usually logs are not part of the public API because they are not something people are supposed to consume in a consistent or programatic way, it looks like in a WAF (by popular demand) they are crucial when it comes to operating a system that consumes this library in any way.

Hence, because software is built on top of use cases, for coraza specifically, we should be assuring that logs are also something to consider when it comes to production readiness.

Expected result

The outcome of this epic should be:

1. identifying the critial outcomes from logs
2. add tests that assert correctness around them
3. Close all the aforementioned issues

[fzipi]

This epic should reflect that there are three different kinds of logs:

• error
• audit
• debug