Enhancing GatewayClass Status API - Conformance features

[LiorLieberman]

The current GatewayClassStatus API is only used to store conditions the controller publishes.

With the evolution of the Conformance tests suite and features, we want to;

1. Enable users easily see what features the implementation support
2. Improving UX and provide clear errors when a user is trying to use a feature the installed GWC doesn't support

Stating this discussion to gather feedback and thoughts before writing a GEP. I will start with a few ideas I've already discussed with some folks.

This is partially related to #1804

Note: I am starting a separate discussion about another enhancement to represent policies/extensions the GWC support.

[LiorLieberman]

1. We could enhance the status field to include a list of supported features. (Perhaps a structured combination of profile and features or just <profile>.<feature> )

2. (from Unsupported feature warning mechanism #1804) We could extend the webhook to validate whether the feature is supported.

[youngnick]

I think that we should just use the same structs as we do in the conformance profile object - this makes the conformance report the same whether it's submitted to the project for validation, or reviewed in the GatewayClass by the user. Plus it's only one place to update.

[LiorLieberman]

On one hand one place to update seems appealing. OTOH I think the profiles now are a bit too structured for a status object. As a user I do not really care about additional metadata the conformanceProfiles apis include now. What I want is to see if my gwc support a feature that I want to use.

Also for the webhook, does the webhook need to care about whether it is core/extended or something else?

Not sure I have the answer in my head, but for sure I think the metadata is not needed. The question is should we reuse the ProfileReport or have something lighter.

I am open to debate