Revisit the threading and ordering guarantees of StreamTracer

Currently `StreamTracer` must be thread-safe, as gRPC doesn't guarantee synchronized invocation for it. While the entire class can't be marked as not-thread-safe, as `inboundUncompressedSize()` may be called from a different thread (app thread) from `inboundMessage()` (network thread), some methods are called sequentially, e.g., `inboundMessage()` and `outboundMessage()`. If a tracer implementation only cares about `inboundMessage()`, it may be totally safe to not to synchronize. We need to find a way to relax the thread-safety requirement to make it easier to implement.

We also need a better definition on the ordering of the methods, e.g., is it possible for `inboundMessage()` to happen after `streamClosed()`?