Replacement API for client/v3/naming package to be compatible with new GRPC1.30+ resolver API.

[ptabor]

This is not yet implementation, just API definitions.

Please review whether the API is good / can be improved. The goal is to reach agreement about
desired layout of the naming/resolver packages in etcd-3.5+, before investement in the implementation of the API.

We propose here 3 packages:

• clientv3/naming/endpoints ->
  That is abstraction layer over etcd that allows to write, read &
  watch Endpoints information. It's independent from GRPC API. It hides
  the storage details.

• clientv3/naming/endpoints/internal ->
  That contains the grpc's compatible Update class to preserve the
  internal JSON mashalling format.

• clientv3/naming/resolver ->
  That implements the GRPC resolver API, such that etcd can be
  used for connection.Dial in grpc.

Please see the [grpc_naming.md](TLDR: Please take a look at the proposed modified 3.5 grpc_naming user guide document changes & grpcproxy/cluster.go new integration, to see how the new abstractions work.

Note: I'm trying to reach agreement on the vision. I would appreciate (when/if accepted) contributions covering the implementation aspect.

@skyao @mcluseau @scDisorder @xiang90

[scDisorder]

for me it looks the way it must to be
and it resolves an issue by the way of grpc documentation
lgtm

[gyuho]

+1 for the package renaming here. This is mostly moving some of the naming resolution code under client/v3 -- do I understand right?

Can you add more details regarding my comments in the PR?

[gyuho]

Where do we use this package?

[ptabor]

Inside implementation of the endpoint.Manager. It describes how we serialize and deserialize the endpoints as JSON, that we persist in etcd.

As client/v3 is being is linked into many customer's application, it's important to distinguish public API surface from implementation details. We could keep it lower-case as well, but I wanted in this PR stress its private.

[gyuho]

I understand that, but client/v3/naming/endpoints/endpoints_impl.go importing this looks like placeholders and not implemented yet?

[ptabor]

Yes. I hope for contributors to implement this within a month. If no one will contribute, I will do the implementation itself.
The endpoints definition is fixed in stone so its why I'm submitting it.

[ptabor]

@gyuho : PTAL

[ptabor]

@gyuho I changed the PR such that its commitable (I left original naming/grpc.go and introduced the new interfaces side by side, and "stashed" the grpcproxy migration&cleanup ).
I propose merging this PR, to unblock other contributors interested in enabling grpc upgrade.

@scDisorder @dhermes @skyao FYI.

[scDisorder]

glad to see that! seems like there is not so much to handle ahead

i'll be literally in touch, when PR would be merged, you can notify me

[scDisorder]

so how it is going? :)

@ptabor @gyuho

sorry if I do bother you :)

[ptabor]

@gyuho Are you OK with me merging this ?

[gyuho]

Can we move this as backlogged GitHub issue? Or put these into internal package? Once we have this public, it's hard to remove. Seems like this has not been implemented?

[ptabor]

Added the issue:
#12652
I assume this will get implemented as part of 3.5.0 (I will contribute if none else).

[gyuho]

@ptabor Thanks!

[gyuho]

endpoints.NewManager(c, "foo")

This has not been implemented "in" etcd, but I understand this is mainly to unblock gRPC dependency upgrades, so we should be ok to leave it not implemented. Or if we aren't going to have example endpoint manager implementation, can we just remove?