xds: fix cluster_resolver LB policy behavior upon receipt of NACKed EDS resource

[easwars]

Let's say the cluster_resolver LB policy receives two discovery mechanisms as part of its configuration: a higher priority EDS and a lower priority LOGICAL_DNS cluster. The cluster_resolver LB policy creates child policy configs only after both discovery mechanisms are resolved.

Let's specifically consider the case where the first EDS response for the higher priority EDS cluster is NACKed by the xDS client. This is handled by the edsDiscoveryMechanism here:

grpc-go/xds/internal/balancer/clusterresolver/resource_resolver_eds.go

Line 72 in 2cd95c7

if err != nil {

The error is propagated to the cluster_resolver LB policy by pushing it onto a channel here:

grpc-go/xds/internal/balancer/clusterresolver/resource_resolver.go

Line 283 in 2cd95c7

rr.updateChannel <- &resourceUpdate{err: err}

At this point, since the cluster_resolver has not created a child policy (because it has not received valid responses from both discovery mechanisms), it will report TransientFailure to its parent here:

grpc-go/xds/internal/balancer/clusterresolver/clusterresolver.go

Line 256 in 2cd95c7

b.cc.UpdateState(balancer.State{

Instead the cluster_resolver should treat this error from the xDS client as though it received an EDS response with a single priority and no localities. This will allow it to create the priority child (once it receives a response from the DNS mechanism as well), and will allow it to fail over to it.

Also, the cluster_resolver LB policy should do the same thing if the EDS watcher returns a resource-does-not-exist error. The only difference between a resource NACK error and a resource-does-not-exist error is that the former ignores the error if there was a previous result, whereas the latter does not.

[ulascansenturk]

Hey @easwars, you can assign me.

[dfawley]

Actually, this one is better off waiting on another item that @easwars is planning to do.

[easwars]

Blocked on #6265.