Add the context on Envoy requests to the audit logs

[sfc-gh-msathe]

This is not yet fully baked and I am here to get feedback on various choices. The motivation here is to bring a traceability between the Coraza audit logs and the envoy request logs by including the x-request-id header value in the audit logs.

This won't affect any of the existing usage as this inclusion is controlled by the include_request_id_in_audit_logs configuration.

I am looking for feedback over:

1. A broad need for this traceability vs just my use case (in which case a fork might suffice)
2. The configuration include_request_id_in_audit_logs vs something broader like include a list of request headers with given labels.
3. Implementation.

I understand this lacks unit tests and the code could be cleaner but I am waiting for a general agreement over the approach before committing the time.

Thanks all!

[jcchavezs]

@sfc-gh-msathe I really love you brought this up.

We have a couple of issues around this in https://github.com/corazawaf/coraza/issues/711 and https://github.com/corazawaf/coraza-proxy-wasm/issues/166 where I was specifically targeting specifically request ID.

What I think we could do as discussed in https://github.com/corazawaf/coraza/issues/711 we could:

1. Add the API in coraza (in the experimental package) where we list variables []string{"REQUEST_HEADERS:X-Request-ID"} which will be used to obtain variables from the transaction that can be displayed in the H part (described as Audit log trailer, which contains additional data). If someone truly believes this will break parsers or something we could propose a new audit log part.
2. Update the formatters to output in the audit logs e.g. [var:REQUEST_HEADERS:X-Request-ID=abc123] in modsec formatter or "vars": {"REQUEST_HEADERS:X-Request-ID": "abc123"} in JSON format.

As per coraza-proxy-wasm we could add the slice include_variables_in_audit_logs: ['REQUEST_HEADERS:X-Request-ID'] to achieve the same.

Thoughts @airween @dune73 @jptosso @anuraaga @M4tteoP