Clarify ParentRef Uniqueness with Port and SectionName

[robscott]

Currently the webhook and CEL validation consider the following valid:

- name: "foo"
  sectionName: "bar"
- name: "foo"
  port: 80

I personally don't think these should be considered unique and instead we should only consider parentRefs unique if:

1. They both specify different section names
   OR
2. They both specify different port numbers

Since the port field in parentRef is still experimental, we still have a window to tighten this validation if we want to.

Thanks to @gauravkghildiyal for catching this in #2320!

[youngnick]

I'm really starting to like the word "distinct" for this sort of thing.

Something like:

parentRefs must be distinct. Distinct in this context means either that:

• they select a different object. If this is the case, then parentRef entries are distinct. In terms of the fields, this means that the multi-part key defined by group, kind, namespace, and name must be a unique one across parentRef entries for this to be considered distinct.
• If they do not select different objects, then for each optional field that's used, each reference that selects the same object must use the same set of optional fields. If one sets sectionName, all must set sectionName. If one sets port, all must set port. If one sets a combination of optional fields, all must set the same combination.

[frankbu]

Maybe a stupid question, but why is it necessary that the references are distinct? Seems simple enough to say that the route applies to the union of the parents, overlapping or not, just like adding entries in a set. Maybe it's a little sloppy, but it's not like it won't work as expected just because the same parent is referenced twice.

[youngnick]

It's more that allowing overlaps doesn't add anything except the possibility of confusion. We slice status by parentRef already, if there can be overlaps, it will create weird edge cases and differences in handling.

As much as I'd like not to have to be this specific, allowing overlapping references is, in our experience, a ticket to trouble-town.