feat: allow caller to initialize the channel

[nmooscisco]

In some scenarios, such as when using a Deterministic Simulation Testing environment such as turmoil, when mocking the behaviour of etcd itself, or using non-Tokio sockets for connecting to etcd, it is desirable to construct a Tonic channel externally, then "wrap" it in a Client object. This patch enables this use case by creating a RawClient type, which is constructed from an existing Tonic channel.

In order to ensure maximum code re-use, the existing Client is updated to use the RawClient type internally.

[davidli2010]

Why not just add the Client::from_channel() function?

[nmooscisco]

That would also work, however, the Client seems to require that the balanced channel Sender be passed into it as well. In the current design for this PR, I have made the assumption that if the caller wishes to use load-balancing, it will handle the load balancing externally, by owning the Sender itself, allowing the caller to handle construction of the connector. It is also possible, in this case, for the caller to use a non-LB Channel if the caller should so desire.

I could also make the Sender optional in Client so as to allow this, or maybe there is another way that I'm not seeing. I'm open to suggestions, thank you!

[davidli2010]

Make the Sender optional in Client is OK, IMO. And I think Client::from_channel() need a feature gate, because it's not recommended.

[nmooscisco]

@davidli2010 Done. I created a new feature gate named raw-channel.

[nmooscisco]

Actually, after some more thoughts, I believe that what will make the most sense, if a caller needs to customize the channel more deeply, would be for the caller to be able to supply their own Service impl that can be wrapped by the generated code. Is this something that would be acceptable for this project?

[nmooscisco]

I had a chance to hack on this a bit more, and a prototype is in #98. This way, generics don't proliferate across the codebase -- the different supported types of Channel are all packaged in the enum provided in that PR.

Let me know what you think! The added flexibility in my change will help out quite significantly when using this crate in environments with dynamic infrastructure.

[nmooscisco]

@davidli2010 Thanks to merging #98, this patch is now ready! Thank you for your reviews.