Large binary size with default tracing handlers

[phu-cinemo]

The binary size of the default OnResponse::on_response implementation seems rather excessive.
Even for a release build with fat-lto enabled, it ends up taking ~68KiB according to cargo-bloat.

We can't use a custom handler easily, because we rely on gRPC status handling.

If DefaultOnResponse cannot become smaller, maybe the machinery for gRPC handling could be exposed?

(this is also true for OnEos, but to a lesser extent.)

[erebe]

Issue can be closed since #380 is merged and released in v0.4.3.

❯ cargo bloat --release -n 10
 File  .text    Size                 Crate Name
 0.3%   0.9% 46.5KiB                brotli brotli::enc::block_splitter::BrotliSplitBlock
 0.3%   0.8% 42.7KiB tonic_key_value_store tonic_key_value_store::main::{{closure}}
 0.3%   0.8% 42.4KiB tonic_key_value_store tonic_key_value_store::main::{{closure}}
 0.2%   0.6% 32.3KiB                    h2 h2::codec::framed_read::decode_frame
 0.2%   0.6% 30.3KiB                brotli brotli::enc::backward_references::BrotliCreateBackwardReferences
 0.2%   0.6% 28.0KiB                brotli brotli::enc::brotli_bit_stream::LogMetaBlock
 0.2%   0.5% 26.2KiB          clap_builder clap_builder::parser::parser::Parser::get_matches_with
 0.2%   0.4% 22.8KiB                   std addr2line::ResDwarf<R>::parse
 0.1%   0.4% 19.9KiB                   std std::backtrace_rs::symbolize::gimli::resolve::{{closure}}
 0.1%   0.4% 18.1KiB                 hyper <hyper::proto::h1::role::Server as hyper::proto::h1::Http1Transaction>::encode
32.3%  92.1%  4.6MiB                       And 12524 smaller methods. Use -n N to show more.
35.1% 100.0%  5.0MiB                       .text section size, the file size is 14.1MiB