tonic-health: expose client

[LukeMathWalker]

Feature Request

Crates

tonic-health

Motivation

Testing a server that exposes the health check service now requires:

• embedding the protos in your own project;
• adding a build script to generate the client.

Proposal

Add a new feature flag, client, to tonic-health to expose a gRPC client for the health check service.
Would you prefer to expose the "raw" client as it comes out of tonic-build or would you prefer to wrap it in a nice Rust API that does not expose the underlying protobuf types?

[LucioFranco]

iirc tonic-health was just for the server side, but I am not opposed to exposing a client. I don't have much time right now to get to this but would love a PR :)

cc @jen20

[LukeMathWalker]

A PR you shall have 🎸
Shall we go for raw protobuf types or "wrapped" up nicely in a Rust-ier shell?

[LucioFranco]

We could expose the pb since I doubt it will change. Just put it into its own module. I think we can then provide a transport feature that enables the connect ability? Not sure tbh

[jen20]

I definitely planned to get to a client at some point! A PR would be great @LukeMathWalker! Personally I'd tend towards exposing a more idiomatic Rust API if possible, though the PB-generated code is not too bad in this case.

[cortopy]

It would be great to have the client generated for health checks. Kubernetes does not support grpc health checks natively and requires either a command line tool or a side container that acts as http/grpc proxy for health checks

[LucioFranco]

Yeah, I agree, we should expose the client and also the proto module (which would include the client).