Clarify semantics and restrictions of user config for Peering and VpcExpose objects

[qmonnet]

When users define Expose objects to connect VPCs, we need to clearly define what is allowed and what is not, and what the meaning of some expressions is. Eventually, this should translate into making sure that the appropriate behaviour (matching the semantics) is implemented, and setting up the relevant validation steps to enforce restrictions.

Related:

• NAT: Clarify what happens when user passes blank prefix lists, non-empty exclusion prefix lists #779

As a reminder, we consider an Expose object as:

• A list of prefixes (and optional associated port ranges - this is coming soon) for internal prefixes exposed, ips
• A list of prefixes (and optional associated port ranges) for actually exposed addresses and ports, after NAT/PAT, as_range
• A list of exclusion prefixes (and optional associated port ranges) to apply to these exposed prefixes, not and not_as (for ips and as_range, respectively).

The lists may or may not be present from the CRD passed by the user.

Here's a non-exhaustive list of items to consider for an Expose object.

1. Can lists be present but empty? Does it change the behaviour compared to when they're not present at all?
2. What happens if ips list is not present?
3. In particular, what happens if ips is not present but if a not list is present?
4. What happens if ips list contains 0.0.0.0/0 as prefix (or ::/0)?
   • With a port range?
   • Without a port range?
5. What happens if as_range list is not present?
6. In particular, what happens if as_range is not present but if a not_as list is present?
7. What happens if as_range list contains 0.0.0.0/0 as prefix (or ::/0)?
   • With a port range?
   • Without a port range?
8. What happens if not or not_as contains 0.0.0.0/0 as prefix (or ::/0)?
   • With a port range?
   • Without a port range?
9. Can a list contain a mix of IPv4/IPv6 prefixes?
10. Can the different lists of an expose contain a mix of IPv4/IPv6 prefixes?
    • Today?
    • In the future for NAT46/NAT64?
11. Can prefixes in ips or as_range lists overlap? (IP addresses overlapping, or if both have port ranges, IP addresses + port ranges overlapping)
12. Can prefixes in not or not_as lists overlap?
13. Can prefixes in not or not_as contain item not in ips or as_range (respectively)?
    • If there's not overlap at all?
    • If there's some overlap? (Example: exclude 0.0.0.0/0, ports 5001-6000 from some ips)
14. Can prefixes in ips for different Expose objects of a peering, once their exclusion prefixes applied, overlap?
15. Can prefixes in as_range for different Expose objects of a peering, once their exclusion prefixes applied, overlap?
16. Can we have multiple peerings between any pair of VPCs?
17. Can prefixes in ips for Expose objects from different peerings between a pair of VPC overlap with prefixes from ips in the Expose of another peering for the same VPCs?
18. Can prefixes in as_range for Expose objects from different peerings between a pair of VPC overlap with prefixes from as_range in the Expose of another peering for the same VPCs?
19. Do we need a particular treatment for some ranges of IPs (0.0.0.0, 255.255.255.255, etc.)?
20. Do we need a particular treatment for port 0 (mostly invalid for TCP/UDP)?
21. When port ranges are in use, what are the expectations regarding ICMP?
22. ...

We should settle on the expectations for each of these items (some of them we already know) and formalise it, so we can document it for the users and implement the relevant behaviour/validation. We should also double-check the existing validation steps.