Expose whether a transaction was allowed (allow action) via the public API

[renanay]

Problem

The allow disruptive action is currently invisible through the public API. Unlike deny/drop, allow never produces an Interruption — it only stops rule processing — so tx.IsInterrupted() / tx.Interruption() don't reflect it. The authoritative state (AllowType) lives on the internal corazawaf.Transaction, which consumers can't import, and it isn't surfaced on the types.Transaction interface.

Today the only ways to observe an allow from outside are indirect and fragile:

• MatchedRule.Disruptive() is true, but it can't distinguish allow from deny/drop/pass/redirect;
• string-matching MatchedRule.Rule().Raw() or the log output for allow / "Access allowed".

Use case: we'd like to increment a metric/counter when a request is allowed through, which needs a stable, transaction-level signal.

There's already a TODO(4.x) on Transaction.Allow about exposing this in the interface, so this may be a welcome direction.

Proposal

Add a public accessor to the Transaction interface:

// IsAllowed reports whether an `allow` action matched during the transaction.
IsAllowed() bool

Implementation sketch:

• Keep enforcement untouched: AllowType still drives phase skipping and stays gated on RuleEngine == On.
• Add a separate observability field, set whenever an allow matches and never reset during phase processing, so it's a stable transaction-lifetime signal. This backs IsAllowed().

I've put together a working patch with positive/negative tests (engine-on, DetectionOnly, and no-allow) as an example of the approach — see: #1636. Happy to iterate on it once there's a direction the maintainers are comfortable with.

Two decisions I'd love feedback on

1. Record in DetectionOnly? I'd propose recording the allow decision in all engine modes, including DetectionOnly, so IsAllowed() reflects what would have happened — consistent with how disruptive actions already remain visible in DetectionOnly (via Disruptive_ / DisruptiveAction_ since 3.4). Enforcement and rule evaluation would be unchanged (rules after the allow still run in DetectionOnly). Does this match the project's intent, or should the signal only reflect enforced allows?
2. bool vs. typed accessor. IsAllowed() bool covers the counter use case. Alternatively (or additionally) an accessor could expose the allow kind (all / phase / request), which would mean promoting that enum out of internal/. Is the richer API worth it, or is a bool preferable?

Compatibility note

This is an addition to the public types.Transaction interface. It shouldn't affect existing users — the interface is implemented within Coraza and external implementations are unlikely — but since it does change the public API surface, you may want to consider it when deciding on the next version.