'ForEachNarrowerOrEqualKey(newKey, ...)' only iterates keys with narrower
or equal IDs (as well as proto/ports). A key is narrower or equal if
'newKey.Identity' is '0' (ANY), or if the iterated key's identity is the
same as the newKey's.

'ForEachBroaderOrEqualKey(newKey, ...) only iterates keys with broader of
equal IDs (as well as proto/ports). A key is broader or equal if iterated
key's identity is '0' (ANY), or if the iterated key's identity is the
same as the newKey's.

Given the above the first condition in the removed code blocks is always
true and the code can be simplified accordingly.

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

Simplify code and clean up comments. No functional changes.

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

Since the removal of CIDR indices and introduction of the transactional
selector cache, there is no difference between the
ForEachBroaderOrEqualDatapathKey and ForEachBroaderOrEqualKey, or
ForEachNarrowerOrEqualDatapathKey and ForEachNarrowerOrEqualKey,
respectively. Remove the "DatapathKey" versions.

No functional changes.

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

Introduce new trie iteration helpers:
- forSpecificIDs calls 'f' for each non-ANY ID in 'idSet'
- forIDs calls 'f' for each ID in 'idSet'
- forID calls 'f' if 'k.Identity' exists in 'idSet'

Use the above to reduce code duplication and replace use of 'forDescendantIDs' with code like:

    if key.Identity == 0 {
        return msm.forSpecificIDs(k, idSet, f)
    }

No functional changes.

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

With transactional selector cache the action `insertBasDeny` is no longer
needed, since the deny entry for the B's identities are already added as
part of A, as in this case A is a deny entry and it includes all the IDs
of B.

Fixes: cilium#34205
Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>

It is possible a new entry is not merged if, for example, the new entry
is an allow entry and a deny entry with the same key already exists. When
this happens the skipped entry should not be recorded as a dependency.

To facilitate the above 'addKeyWithChanges()' now returns 'true' if the
entry was added or merged, or 'false' if the entry was skipped.

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

Allow entries with an default auth type should "inherit" the explicit
auth type of the most specific covering key. Currently we use
'IsSuperSetOf()' to figure out if a key is a covering key to another. We
used to consider keys with the wildcard identity to be less specific than
the keys with a specific identity, regardless of the protocol and
destination port fields. This seems wrong; consider the following example
with three keys/entries:

n ID/proto/port	auth type
3. 43/TCP/80    default auth type
2. */TCP/*      explicit type 2
1. 43/*/*       explicit type 1

Both keys 3 & 2 are covering keys for key 1. The current 'IsSuperSetOf()'
considers 3 to be more specific than 2. Neither of 3 or 2 is a covering
key for each other, so there is some space for interpretation in which of
them should be considered more specific. We have recently changed the
datapath to always consider a key with a more specific
protocol/destination port to be considered the more specific one, and
when they are the same, then consider the key with a specified identity
to be more specific than the key with a wildcard identity. Similarly, for
explicit auth propagation we should consider key 2 to be more specific
covering key for the key 1, as it has more specific L4 (protocol/port)
than key 3.

When inserting key 3, we failed to record key 2 as possibly more specific
key to key 3. 'authPreferredInsert()' is adjusted to note wildcard
identity keys with an explicit auth type as possibly more specific
covering keys than the key being added, so that the auth type of the
entry 3 is not propagated to entry 1.

An existing unit test is modified to reflect this example.

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

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