Deny entries covered by another deny CIDR entry must be kept as they have
different numerical identities in the datapath. Otherwise a later added
allow-all entry could take effect if there is no specific match for the
left-off identity. Simplest example of this is with L3-only deny rules
and an Allow-all rule that wildcards also the L3. So for the sake if this
example we only need to consider L3-identities of the CIDRs (10/8, and
10.1.1.1/32, first covering the latter), say X and Y (both nonzero) and
an allow rule with ID 0 (ANY). This policy should allow all traffic that
is not with an IP covered by 10/8. Since 10.1.1.1/32 is covered by 10/8
it would be tempting to not insert the rule for the ID assigned to CIDR
10.1.1.1/32 to the datapath policy map. The identities for both CIDRs
are, however, present in the ipcache, so that traffic to (or from)
10.1.1.1 would be associated with ID Y, which would match the wildcard ID
(0): allow rule, if a deny rule with the ID Y is not present in the
datapath. Hence, we must both deny rules in to the policy map.

The above logic does not apply when the two rules in question have the
same ID (but different coverage on port and protocol), or when one of
them is a wildcard L3 rule (with ID 0). In that case we can leave the
more specific deny rule covered by another off the policy map, but only
if it was not needed to cover for a L4-only allow rule that still needs
to take effect on all L3 identities not explicitly denied. In that case
we add new L3/L4 deny entries to carve holes into the broader allow rule,
and we must keep the deny rules we added for those holes even when they
would otherwise be covered by a broader deny rule.

Note that a presence of a wider allow rule is not required at the time of
policy map entry insertion for the above consideration to take effect. In
this line of thought we could simply leave off all the deny entries if no
allow entries exist, since the datapath is deny by default. This breaks
down as soon as an allow rule is inserted to a now empty policy map
(maybe incrementally due to an FQDN policy rule):, as all the
(non-inserted): deny rules would now be disregarded.

This leaves a possibility for a late-stage policy map optimization,
however: If, when syncing the userspace policy map to the bpf datapath
policy map, we notice that some deny entries are not covered by any wider
allow entries, it would be safe to leave such entries off from the
datapath policy map. We'd need to be ready to insert them before any new
related allow entries are added, though.

Also, when adding an allow entry that is a subset (in L3-wildcard or CIDR
sense) of an exising deny entry and the new allow entry has a less
specific port-protocol than the deny entry (e.g., wildcard L4 allow and
TCP deny) then an additional deny entry with the identity of the new
allow entry must be added. This ensures that the deny rule takes effect
also for the subset identity at the port/proto of the deny rule.

Unit tests are adjusted, not only to include the previously missing
entries, but also add "allow-all" rules for illustrative purposes so that
it is easier to reason about the necessity of the added deny entries.

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>