Add CDS protocol integration into XdsClient. gRPC client interacts with XdsClient for CDS results via adding a cluster watcher to receive cluster information from traffic director. Multiple watchers can exist to receive cluster information for the same or different clusters.
This change implements EDS protocol in XdsClient, which requests for endpoint information for a given cluster for gRPC's load balancing usage. Note EDS is a quasi-incremental protocol, which means each response may contain only a subset of present resources. Absence of resources should be revealed by response timeout. Currently, timeout is not implemented, endpoint watchers will wait indefinitely if endpoints for the cluster interested in does not exist.
Currently `LoadStatsStore` is create by `LocalityStore` and `LoadReportClient` retrieves `LoadStatsStore` from `LocalityStore.getLoadStatsStore()`.
But `LocalityStore` is create by EDS policy, whereas `LoadReportClient` and `LoadStatsStore` should be created by CDS (if not EDS-only), before `LocalityStore` is created. If `LoadReportClient` is embedded in `XdsClientImpl`, it need a `LoadStatsStore` which shouldn't be created by `LocalityStore`.
Instead, `LoadStatsStore` should be create before `LocalityStore` is created, and be passed to `LocalityStore`'s constructor. A getter is not needed.
Implement envoy's LDS and RDS protocols in XdsClient. gRPC has a special purpose xDS resolver to instantiate an XdsClient object and add a watcher to initiate xDS communication with management server to retrieve information used in service config, which configures gRPC's load balancing plugin.
This is a refactor of the existing xds policy to use XdsClient. It does neither create a copy of EDS policy as in #6371 nor re-implement an EDS policy. This should be similar to the idea of https://github.com/grpc/grpc/pull/20368 in C-core.
Here it refactors `XdsComms2` to an implementation of `XdsClient`, which can be drop-in replaced by `XdsClientImp` when it's available.
Let child balancer (currently is Round Robin) handle the address list with only healthy addresses for its locality. If no healthy address available, let the child balancer handleNameResolutionError.
This change cleans up the definitions of gRPC's data types for envoy's proto messages. These data types carry only information needed for gRPC's logic extracted from envoy's proto messages. Each data type has a static method to convert from its corresponding envoy's proto.
Existing Bootstrapper is an eagerly loaded singleton and reading bootstrap file is done when first time referencing Boostrapper class. This is not use friendly for error propagation.
This change added an instance method Bootstrapper#readBootstrap() for reading the bootstrap file. Instead of making the Bootstrapper instance a singleton, make the bootstrap data (aka, BootstrapInfo) a singleton. Now reading the bootstrap file happens when the first Bootstrapper instance first time calling Bootstrapper#readBootstrap().
Defines an XdsClient interface, which is the blueprint for the class that encapsulates all of the logic for communicating with the xDS server. Also defines watcher interfaces for watching CDS/EDS updates.