Improving Gateway provider feature support documentation

[Rycieos]

The conformance tests that this project has built are a great tool for both those building Gateway providers and those looking to start using one. However, there is a lot of room for improvements in exposing the conformance report information in easily accessible ways.

The base of improvements in this space is a clear mapping between conformance test cases, API fields (+ enum values), and feature names. Currently, if a user wants to know if an implementation supports a specific extended API field, there is no obvious way to know which conformance test case checks for that feature. Related: #2108, #2118, #2285.

I think this discussion should be broken down into specific user stories, to allow for users to vote on specific use cases and to thread discussions on specific use cases.

I will be adding some of my own stories, please add your own.

[Rycieos]

I want to be able to look at a table, where each row is an extended feature, and each column is a Gateway implementation. Each cell would be a ✔️ or ✖️ , which would show if the implementation supports the extended feature.

The table should be able to be filtered, where rows and columns can be hidden from the view with checkboxes. This would enable hiding rows with features that I do not need, and hide implementations that I eliminate if they do not include the features I need.

This table can be built from the submitted conformance reports from implementations.

[Rycieos]

As an implementer, I want a tool that will take a conformance test report as an input, and output a compatibility matrix or table in HTML format that I can embed in my documentation to show what extended features my implementation supports.

[Rycieos]

I want a tool that will take one to many YAML documents as an input, and output a list of extended features that those objects require.

For example, given this YAML document:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
spec:
  addresses:
  - 128.66.0.1
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: ALL

The tool would output:

GatewaySpec.addresses

or some other name for the extended feature that can be matched to the compatabiliy matrix.

This would let a user see what extended features they require for their object specifications, and then compare that to what features implementations support to find the right implementation.

Bonus points if this is an extension to gwctl, and it can automatically pull resources from one to many clusters.

[youngnick]

Hmm, I think that #2550 also covers some of this ground, although I really like the specific requests in this discussion, thanks @Rycieos!