Add tracing spans to public Client RPC methods

[divbhasin]

Summary

Adds tracing::info_span! to the public RPC entry points on Client, MultiReader, and MultiWriter so callers with a tracing subscriber can observe per-call latency, span hierarchy, and errors for their ZooKeeper operations.

The crate already uses tracing internally (#[instrument] on session functions, tracing::error! in the watcher loop). This extends the same pattern to the public API surface.

What's instrumented

Client::{mkdir, create, delete, get_data, set_data, get_and_watch_data, check_stat, check_and_watch_stat, get_children, get_and_watch_children, sync}, plus MultiReader::commit and MultiWriter::commit.

Each call opens an info_span!("zk.<op>", path = %path) (or kind = "reader" | "writer" for the multi
variants) and records Err outcomes via a tracing::error! event so tracing-opentelemetry and similar
subscriber bridges mark the span as errored.

Testing

This has been tested with our internal usage of the client.

[kezhuw]

Errors are semantic apis. It is callers' responsibility to do whatever they want.

zookeeper-client logs wire requests/responses at "debug", state changes at "info", expected failures at "warn", and unexpected failures at "error". I think it is suitable as a library.

The two spans are there for reasons:

1. There are hard works behind the blocking operations.
2. Carry session info to logs.

In contrast, most client apis are simple request-response style channels to get responses.

I guess you probably should wrap the client somewhat to fit your application needs.