ACL profiles - when tags at "deny bot" and "deny" columns, the evaluation flow is not as described at manual
Describe the bug
https://docs.curiefense.io/settings/policies-rules/acl-profiles
As described at manual, the evaluation flow is:
"Evaluation is performed from left to right:
The incoming request is evaluated to see if it matches any of the tags in the far left column.
If a match is found, that column's action is performed, and no further evaluation is done. "

When we have tag match for "deny bot" column and tag match for "deny" column, the "deny bot" is on left side from "deny", so we expect the challenge be activated. Actual result: no challenge, "deny" by tag that match "deny" column.
To Reproduce Steps to reproduce the behavior:
-
Go to ACL Profiles -> create profile with: "deny bot" match:all "deny" match:tag2

-
Send with curl request to match both tags.
-
Actual result: no challenge, request blocked by tag2

Expected behavior
Challenge, blocked by "deny bot" tag:all.

Desktop (please complete the following information):
- OS: MacOS
- Browser chrome
Additional context nginx deployment
The blocking logic should have been sound, but the logging was wrong. PR #726 should fix this.
@bartavelle Now, the logging show block reason: tag "all" although request is tagged "human" and blocked by "tag2".

I expected: block reason:tag "all" - when request is "bot"; block reason:tag "tag2" - when request is "human".
PR written :)
@bartavelle When I send 2 requests with curl (bot): first request with tag "all" and second request with tags "all" and "tag2". Both requests can't pass the challenge and blocked by tag "all". But the log shows different status, block reason, block reason initiator.

First request:

Second request:

I expected same status (247), same reason initiator (phase01), block reason (challenge). Why the difference?
One of them could pass the challenge, because humans are allowed, so the challenge is proposed. The other can't pass even if human, so it is denied.
This needs to be discussed!
Another observation: According to the issue https://github.com/curiefense/curiefense/issues/525, ACL Policies check both Deny Bot and Allow Bot even when the ACL is not active in its respective URL Map. In the case above, the challenged (Deny Bot) isn't proposed when ACL is not active.