policy: Describe CIDR superset logic for denies and FQDN

[joestringer]

This commit attempts to elaborate on the design decisions that have
introduced the need for the mapstate entry merging layer to handle
CIDR supersets.

There is a part of me that would be fond of removing all CIDR superset
evaluation logic from the mapstate layer in order to simplify the logic
and reduce iteration while handling incremental updates. I might argue
that in an ideal world, CIDR policy overlaps would be handled at the
selector layer, ie when evaluating L4PolicyMap / L4Filter against a set
of identities to generate MapState. In such a world, there would be no
need for incremental policy calculation to iterate through all current
mapstate in order to evaluate conflicts between CIDRs in the policy
rules. However, for now this is how we implement the policy correctly
and (relatively) efficiently. In the absence of a more concrete proposal
in that direction, it's worthwhile at least documenting the background
here. This may assist the contemplation of how newer implementations at
the mapstate layer (such as policy auth) may interact with identities
where those identities have a superset relationship with other CIDRs.

[nathanjsweet]

Wow, that is a fantastically accurate, succinct, yet comprehensive summary of policy map insertion and why it is so complex. Thanks!

[christarazi]

Thanks, this was surprisingly easy to parse and understand!