In the review of #5466, the issue of partial rejections (when some resources have errors, but you still want to apply the rest and tell the xDS server you did so) came up. It was previously requested/discussed in #3079, but the current thinking is that only incremental xDS will have this feature, so I figured it deserved a new issue.

The incremental xDS gRPC protocol, as defined by IncrementalDiscoveryRequest, does not currently support partial rejections; there is just a single "here is why everything failed" grpc::Status field, just as in standard xDS. How should this proto support the partial rejection feature?

@htuch and I briefly discussed how this might be done, and saw two options so far:

• Replace the grpc::Status error_detail field with a repeated grpc::Status field, expected to be as long as the number of resources in the previous IncrementalDiscoveryResponse. Entries correspond by index to the resources in that previous message.
• Have a map from resource names to errors. This approach would be complicated by the fact that resource name lives inside an opaque Any.

There is also the question of whether we want to be able to distinguish between "each and every resource individually had errors" and "your whole update attempt had an error", i.e. whether the existing error_detail field should remain alongside the new partial rejection mechanism.