dnsdist: Support DNSAction.Allow in DynBlocks for testing purposes

[lochiiconnectivity]

Short description

Supports DNSAction.Allow in DynBlocks for testing purposes, based on discussion in the IRC channel on 31/05. Also makes documentation more verbose.

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• [] added or modified unit test(s)
• checked that this code was merged to master

[rgacogne]

Thank you for this pull request! Code looks pretty good. I'm a bit concerned about the fact that in this current version, DNSAction.Allow definitively accepts the query, bypassing any rules. While this is consistent with the behavior of DNSAction.Allow in other places, it does prevent using it to test dynamic blocks if you also want the other rules to still apply. Perhaps we need a DNSAction.NoOp or something like that?

[rgacogne]

I'm not sure the switch is needed there, but perhaps we could at least collapse it into two single blocks since all blocks are the same except for the default, so something like:

case DNSAction::Action::Allow:
case DNSAction::Action::Drop:
case DNSAction::Action::Refused:
case DNSAction::Action::Truncate:
  g_dynBlockAction = action;
  break;
default:
...

[lochiiconnectivity]

Ack, will collapse the switch statement.

With regards to the rule processing, how about permitting the use of DNSAction::Action::None here?

[rgacogne]

Right, it looks like DNSAction::Action::None would work for setDynBlocksAction(), although it wouldn't for the optional action parameter of addDynBlocks() since we already use None there to indicate that the default action should be used. I don't think that's an issue, but we would need to make that clear in the documentation.

[rgacogne]

I'm closing this pull request because it looks like it has been superseded by #6776, please correct me if I'm wrong and thank you again!