fix: add BackendTLSPolicy features to GATEWAY-HTTP profile

[snorwin]

What type of PR is this?

/kind bug
/area conformance-test

What this PR does / why we need it:
This PR ensures that the BackendTLSPolicy conformance tests are properly included in the conformance profiles and reflected in the generated reports. Currently, these tests run successfully but don’t appear in the report because they aren’t associated with any profile

Which issue(s) this PR fixes:

Fixes #3936

Does this PR introduce a user-facing change?:

Added BackendTLSPolicy features to GATEWAY-HTTP profile

[snorwin]

/cc @shaneutt @candita

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: snorwin
Once this PR has been reviewed and has the lgtm label, please assign arkodg for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• conformance/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[snorwin]

I added now the BackendTLSPolicy Core feature to the Extended features of the profile, I wasn’t sure if the overall BackendTLSPolicy is considered Core or Extended.

[candita]

I wonder if we should create a new profile for Policies.

[snorwin]

In my opinion, I don’t think it’s worth creating a new profile at this point. Currently, there are only two features that would be part of such a dedicated profile, and both require the Gateway and HTTPRoute feature to execute the tests anyway. Therefore, it would make much more sense to include them under GATEWAY-HTTP for now, and potentially later also under GATEWAY-GRPC and GATEWAY-TLS, once we’ve written the corresponding conformance tests.

The main question for me is whether BackendTLSPolicy is considered part of the Core or Extended. I couldn’t find any information about this in the GEP. If we add it to Core, all implementations would need to support it before achieving conformance for version 1.4, which, in my opinion, would be quite challenging for some. Therefore, I’d suggest adding it as part of the Extended features for now.

[youngnick]

The guideline is that all additional objects should be considered Extended unless there is a good reason.

This comes back to "what does Extended mean?". The word "Extended" is relevant for a field and all of its child features. So, when a whole object is Extended, that means that you don't have to support that object. However, if you do support it, then within that object, Core features are MUST, and Extended features are SHOULD.

So, the BackendTLSPolicyExtendedFeatures really require BackendTLSPolicyCoreFeatures and BackendTLSPolicyExtendedFeatures.

So, yes, I agree that BackendTLSPolicy should be Extended. At some point, it may be worth moving it into overall Core support for the HTTP Profile, but not yet.

[snorwin]

@youngnick Just to make sure I understand correctly, are you suggesting that we add BackendTLSPolicyCoreFeatures to BackendTLSPolicyExtendedFeatures, or should we keep the change as it is?

[candita]

I'd like to see features.BackendTLSPolicyCoreFeatures added to a new conformanceProfile for policies.

Suggested change

	features.BackendTLSPolicyExtendedFeatures,
	PolicyConformanceProfile = ConformanceProfile{
	Name: GatewayHTTPConformanceProfileName,
	CoreFeatures: sets.New(
	features.BackendTLSPolicyCoreFeatures,
	),
	ExtendedFeatures: sets.New[features.FeatureName]().
	Insert(features.SetsToNamesSet(
	features.BackendTLSPolicyExtendedFeatures,
	...