api: CSDS should report status per resource, not per resource type #14431
Description
The current CSDS protos have the status and client_status and fields at the resource-type level, not the level of individual resources. They also provide the SotW system version (for LDS, RDS, CDS, and EDS), which is effectively a per-resource-type version.
This representation doesn't seem capable of representing the underlying reality, because the transport protocol allows the client to ACK/NACK a strict subset of resources at a given system version. Here are some scenarios that are not made clear by this representation:
- Server sends RDS response containing resources A and B at system version 1, and client ACKs. Then resource B is updated, so server sends RDS response containing resource B at system version 2, and client NACKs. At this point, client has ACKed resource A at system version 1 but has NACKed resource B at system version 2 (so is still using resource B at system version 1).
- Client subscribes to LDS resources A and B. Server sends both resources at version 1, and client ACKs. Now client subscribes to resource C. Server sends a new LDS response containing resources A, B, and C, all still at system version 1. Resource C is invalid, so client NACKs. At this point, the client is actually using the current version of resources A and B, but it has NACKed C, all at the same version.
- Pretty much any scenario using the incremental protocol variants. Unlike the SotW protocol variants, the incremental variants do not use the system version at all; instead, they report a version for each individual resource, and ACK/NACK is based on that version instead of the system version.
I think CSDS should be changed to report both version and status on a per-resource basis instead of a per-resource-type basis. When using the SotW API, the per-resource version can actually be the system version, but it should still be reported on a per-resource basis, since it can be different for different resources.
For bonus points, in the case where a resource was NACKed, it might be useful to report both the version that was NACKed and the older version that is actually still being used (if any).