Support HTTPRoute Condition `RouteConditionReady`

[arkodg]

Description:
Populate the GatewayConditionReady condition on the Gateway listener when its corresponding xDS resources have been programmed in envoy and acknowledged by it.

relates to kubernetes-sigs/gateway-api#1833

[arkodg]

the xDS protocol behavior around NACKs is defined here https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#nack
we would need to

• peek into the error_detail field within DeltaDiscoveryRequest

  gateway/internal/xds/cache/snapshotcache.go

  Line 306 in 0af4f19

  func (s *snapshotCache) OnStreamDeltaResponse(streamID int64, req *discoveryv3.DeltaDiscoveryRequest, resp *discoveryv3.DeltaDiscoveryResponse) {

• if its empty, we get update the Gateway listener status, set Ready=True, and publish it using something like

  gateway/internal/gatewayapi/runner/runner.go

  Line 103 in 0af4f19

  for _, gateway := range result.Gateways {

• above involves also passing Gateways all the way to the xds-server, increasing memory footprint, we can optimize that in the future by only passing Gateway statuses

[arkodg]

assigning this to @chauhanshubham who is interested in picking this one up, thanks !

[arkodg]

note, ive edited the title, to highlight that we plan on updating the Ready Condition associated with the HTTPRoute, not the Gateway

[chauhanshubham]

It's a bit tricky at this time to determine and trace the NACK request error to a particular Route object.
Although we use delta requests, but the requests can be clubbed for multiple route objects in a single snapshot too.

Scenario 1:
Lets say we create httproute, tlsroute and then the gateway (containing http and tls route references) - in this particular order. The snapshot will be created at the last step -> when the gateway is created.
If only the tlsroute related resource had an issue, the httproute traffic would also not function, because of the snapshot error.

Scenario 2:
Create the gateway and httproute first, wait for envoy to be configured, and then create errored tlsroute configurations. This time around, the delta snapshot will error out. Now httproute traffic will work fine, but tlsroute would not work.

This means same configurations can lead to two different scenarios. Which in turn means that, assuming we complete this task, the route status cannot be deterministically set.

Will need to think more about this. Just posting some initial observations.

[arkodg]

thanks for running these tests @chauhanshubham !
imo we should treat all scenarios like scenario 1 where we cannot determine the order of resources received and must update status of all child resources xRoutes to Ready:False if any error is encounted for a snapshot, because order can change pre/post EG restart

[chauhanshubham]

Also, an error doesn't really mean that the traffic on the xRoute would stop working. It's just that the errored configuration would be rejected, once tried after a valid configuration.
Should that be a Ready: true to Ready: false transition candidate.