lazy loadable EDS cluster

[lambdai]

Background:

The control plane may don't have adequate information to predict what cluster Envoy needs. The currently known approach is to including all possible clusters in the CDS response and all these cluster names will be send to EDS server.
The EDS server will keep envoy updated with the latest endpoints in those clusters.

#Problems:

1. EDS response on the wire is large. Partial will be resolved by LEDS.
2. Not all clusters are required. One possible reason is that control plane cannot tell which cluster is needed. Another potential reason is that some cluster are supposed to be used sparsely.

Solution

1. Introduce lazy load EDS cluster. Various laziness strategies will be discussed in design doc. Providing trade offs among control plane availability and resource usage.
2. Provide ClusterManager futureThreadLocalCluster to request cluster and get notification on the cluster readiness event.
3. No need to touch the existing control plane!

Related Proposal

1. LEDS: independently resolve the EDS bytes on the wire. Locality endpoint discovery service (LEDS) #10373
2. On Demand CDS Generic Dynamic Forward Proxy with On Demand CDS #15026 . Probably the laziest. Require co-op of control plane. Demand high SLO of control plane.

[lambdai]

Design doc: https://docs.google.com/document/d/1-QgiqOCq8EcQO1cO22dRFKpuUglQp_pKZVXFCPmMSJQ/edit?usp=sharing

[lambdai]

Close this one in favor of lazy CDS as per community meeting 03/09/2021: https://docs.google.com/document/d/1Yc4zkV-A_cC_R3C0u6D15WQAsRSxADs8p2l8UMMa4P4/edit#