xds: Introduce new generic xDS and LRS clients decoupled from gRPC-specific elements and migrate internal xDS and LRS functionality to use new generic clients

[purnesh42H]

Use case(s) - what problem will this feature solve?

Stabilize the gRPC-Go xDS client and decouple from gRPC-specific elements to make it suitable for broader use. This involves removing dependencies on gRPC code related to client configuration, resource validation, and monitoring. By making these changes, a more generic xDS client can be created and exported for use outside of gRPC.

Proposed Solution

• Create a client instance with an in-memory configuration that consists of the node configuration, an authority map with xds server configurations, transport builder to build your own transport and credentials to use for each xDS server.
• The xDS client allows for creating watches for named resources that can be received on an ADS stream.
• The xDS client should support federation and fallback.
• At initialization time, the application can provide resource processing functions for these resources.
• The xDS client will cache processed and unprocessed resources.
• The xDS client can provide raw CSDS data.
• The LRS client should also allows to report load through LRS Stream.

Tasks

• xds: introduce generic xds clients common configs
• xds: introduce generic xds clients xDS and LRS Client API signatures
• xds: introduce simple grpc transport for generic xds clients
• xds: generic xDS client transport channel and ads stream implementation
• xds: generic xds client resource watching e2e
  • xds: add MetricsReporter for generic xds client
  • xds: modify generic clients grpctransport to accept optional custom grpc new client function
  • xds: generic xds client ads stream tests
• xds: generic lrs client for load reporting
• xds: migrate internal xdsclient to use generic client and dedicated LRS client