Make single TargetRef Core for BackendTLSPolicy (#4298)

Make Core conformance for BackendTLSPolicy only support
a single TargetRef for now, while we figure out what to
do about representing some edge cases in status.

Signed-off-by: Nick Young <nick@isovalent.com>
Co-authored-by: Nick Young <nick@isovalent.com>

Author: k8s-infra-cherrypick-robot

apisx/v1alpha1/xbackendtrafficpolicy_types.go

@@ -69,6 +69,10 @@ type BackendTrafficPolicySpec struct {
 	// Currently, a TargetRef can not be scoped to a specific port on a
 	// Service.
 	//
+	// Because of concerns over recording status correctly in some edge cases,
+	// currently, Core support is only given to one (1) TargetRef. More than
+	// one TargetRef is Implementation Specific.
+	//
 	// +listType=map
 	// +listMapKey=group
 	// +listMapKey=kind

config/crd/experimental/gateway.networking.x-k8s.io_xbackendtrafficpolicies.yaml

@@ -625,6 +625,20 @@ While in some cases adding new fields may be seen as a backwards compatibility r
 knowing to respect the fields, these fields (or similar, should future GEPs decide on new names) are pre-approved to be
 added in a future release, should the GEPs to add them are approved in the first place.
 
+## Outstanding issues
+
+### Multiple TargetRefs rolling up to the same Gateway cannot be represented in status
+
+It is possible to have a BackendTLSPolicy target multiple, different Services that are used in HTTPRoutes that attach
+to the same Gateway.
+
+As written, the Status section of BackendTLSPolicy does not have a way to represent these separate statuses, as the
+status is namespaced by `controllerName` and `ancestorRef` (where "ancestor" is the Gateway in this case).
+
+We need to decide if this is enough of an issue to change the status design, or if we record this as a design decision
+and accept the tradeoff.
+
+
 ## Alternatives
 Most alternatives are enumerated in the section "The history of backend TLS".  A couple of additional
 alternatives are also listed here.