xds: introduce generic xds clients xDS and LRS Client API signatures

[purnesh42H]

This is the next part of generic xds clients to be usable outside of grpc which builds on top of #8024. This change is adding the user API signatures for xDS and LRS client (without implementation) to communicate with xDS management server.

POC
Internal Design

RELEASE NOTES: None

[codecov]

Codecov Report

Attention: Patch coverage is 54.09836% with 28 lines in your changes missing coverage. Please review.

Project coverage is 82.36%. Comparing base (7505bf2) to head (b6ac539).
Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
xds/internal/clients/lrsclient/load_store.go	0.00%	12 Missing ⚠️
xds/internal/clients/xdsclient/xdsclient.go	0.00%	8 Missing ⚠️
xds/internal/clients/lrsclient/lrsclient.go	0.00%	4 Missing ⚠️
xds/internal/clients/internal/internal.go	88.88%	3 Missing ⚠️
...s/internal/clients/grpctransport/grpc_transport.go	90.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8042      +/-   ##
==========================================
+ Coverage   82.32%   82.36%   +0.03%     
==========================================
  Files         388      392       +4     
  Lines       39016    39132     +116     
==========================================
+ Hits        32121    32232     +111     
- Misses       5574     5585      +11     
+ Partials     1321     1315       -6     

Files with missing lines	Coverage Δ
...s/internal/clients/grpctransport/grpc_transport.go	84.90% <90.00%> (ø)
xds/internal/clients/internal/internal.go	88.88% <88.88%> (ø)
xds/internal/clients/lrsclient/lrsclient.go	0.00% <0.00%> (ø)
xds/internal/clients/xdsclient/xdsclient.go	0.00% <0.00%> (ø)
xds/internal/clients/lrsclient/load_store.go	0.00% <0.00%> (ø)

... and 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[purnesh42H]

@dfawley i did the godoc review and made following changes (see the last commit)

• removed the helper methods on struct that are not being used to avoid exporting them. we can add later during implementation.
• removed square brackets from docstrings because actual param and struct field already has the link to respective object definition.

[dfawley]

Let's leave "old" and "style" out of the docstrings and describe what it is or what it is used for in specific terms instead.

[purnesh42H]

I have modified the documentation. One more thing i have added in both Authority and here about order of servers in the list for precedence. Let me know if thats okay. I remember there was a question recently about how the fallback servers are chosen. Should we mention the gRFC as well?

[purnesh42H]

@dfawley I have moved the config helpers and test to internal package because 1) we don't want to expose them 2) we don't want user to have proto dependencies.

[dfawley]

This seems basically done, just some very minor things left.

[dfawley]

Is xdsclient using this? If so, how? I was thinking it would just be the transport implementation that needs something like it?

[purnesh42H]

So, it will be used to de-duplicate the transport channel. Yes, the transport will need it. Also, when de-duplicating xDS channel the xDS ServerConfig equality check will call it as well.

[dfawley]

So then only our transport implementation can use it if it's in internal. Maybe let's delete for now and add when needed and we can talk about how it should work and where it should go.

Because what we really need is ServerIdentifiers as map keys. But that's not directly possible, unless the any is compatible, perhaps?

[purnesh42H]

Think its the same discussion #8042 (comment). Basically, it will be needed in xDS client implementation as well for server config because ServerIdentifier is embedded in that.

[dfawley]

We don't have an Equal method, but our own docs recommend one? Are we sure we actually need one? If only the transport would need it, then I don't think we do.

[purnesh42H]

We will need it when de-duplicating the transport channel. That will come in final xDS client implementation PR. I was thinking of adding it at that time. Why do you think we won't need one?

[dfawley]

Deduplicating will require it to be a map key, not to have an Equal method.

[purnesh42H]

I don't think we can hash the complex fields like extensions right? So, we need a equal method to get the right key for the map and then lookup that key. Something like done here for xDS Server Config

grpc-go/xds/internal/xdsclient/authority.go

Line 531 in bffa4be

if a.activeXDSChannel != nil && a.activeXDSChannel.serverConfig.Equal(serverConfig) {

.

So, ServerConfig needs equal method and in turn we need to check equality for embedded ServerIdentifier. I don't think we can get away without equality unless every field has a String() method.

[purnesh42H]

@easwars wdyt?

[purnesh42H]

Discussed internally with @dfawley. For now, we can remove and see if we can find other ways to tackle comparing channels.