NAT: Support empty `ips` (respectively `as_range`) with non-empty `not` (respectively `not_as`) prefix lists

[qmonnet]

The user API for gateway allows users to specify an empty internal prefixes list (ips in dataplane's code) with a non-empty list of excluded prefixes (not) for an expose object. My understanding is that, in that case, we consider that the user wants to use IPs from the whole IP addressing space, except for the excluded prefixes. The same is allowed for the lists of publicly exposed IPs (empty as_range with non-empty not_as).

We don't support such configurations in the current NAT code, however. Therefore, we forbid it at validation time in #648.

This issue is to track this mismatch between the user API and the current restrictions in the code. We need to solve this either way:

• by restricting the user API to forbid such configurations, if we decide it doesn't make sense,
• or by adding support accordingly in the dataplane.

[qmonnet]

Copied from #661, and related to VpcExpose overlap verification:

Another issue arises when an expose object has an empty ips or as_range, but a non-empty corresponding not or not_as. In that case, we don't check overlap correctly because the VpcExpose object does not, initially, contain a root prefix (such as 0.0.0.0/0) on which to “apply” these exclusion prefixes, making it hard to check whether they overlap. Again, this would be easier to address if we had already optimised the expose objects prior to validation. Note that this second issue is currently prevented by the fact we reject configurations with exclusion prefixes only (see #650), but it stands in the way if we wanted to support such configurations.

Note: I don't remember the exact semantic of an expose with no allowed prefix - we need to clarify that, first.