[Rust] Make the gRPC transport layer pluggable for internal framework integration

[teodordelibasic-db]

SDK

Rust

Description

The Rust SDK currently has a hard dependency on tonic::transport::Channel for gRPC communication. In the future when we have internal services written in Rust that want to ingest using Zerobus, they will use RAF (Rust Application Framework) for inter-process communication. RAF provides its own GrpcChannel — a tonic channel wrapped with tower middleware layers for context propagation, metrics, tracing, and health events (analogous to how Scala services use Armeria's GrpcChannel instead of raw gRPC-Java channels).

To support this, the SDK needs to allow swapping the underlying gRPC channel implementation without breaking the existing OSS API.

Proposed Solution

One potential solution:

1. Make the SDK generic over the channel type — Replace ZerobusClient<Channel> with ZerobusClient<C> where C: GrpcService<BoxBody> + Clone + Send + Sync + 'static, using C = Channel as the default so existing usage is unaffected.
2. Extract a ChannelFactory trait — Move channel construction (Endpoint::from_shared, .connect_lazy(), TLS, proxy setup) behind a trait. Provide TonicChannelFactory as the default OSS implementation. Internal consumers provide their own factory (e.g. wrapping RAF's GrpcChannel with ClientConfig).
3. Feature-gate the tonic transport — Put TonicChannelFactory and direct tonic transport code behind a tonic-transport feature (enabled by default). Internal consumers can disable this feature and supply their own channel factory.

No breaking changes — the default type parameter and default feature flag preserve full backwards compatibility for OSS users.

Additional Context

• RAF's GrpcChannel already satisfies tonic::client::GrpcService<BoxBody> since it's a tower layer stack on top of tonic Channel, so ZerobusClient<GrpcChannel> works without additional adaptation.
• The HeadersProvider trait for auth/header injection can coexist with RAF's CtxPropagationLayer; internal consumers would likely skip custom header injection and let RAF's middleware handle it.
• The Arrow Flight experimental path (arrow_stream.rs) has similar coupling and would benefit from the same treatment if needed later.