关于ChannelOptions的timeout_ms的疑问

**Describe the bug (描述bug)**
不是bug，里面没有提问类别，就提这个了。

[官方文档](https://brpc.apache.org/zh/docs/client/basics/#%E8%B6%85%E6%97%B6)里面描述：
> ChannelOptions.timeout_ms是对应Channel上所有RPC的总超时，Controller.set_timeout_ms()可修改某次RPC的值

"对应Channel上所有RPC的总超时"这个怎么理解，比如我channel设置timeout是3秒，这个时候如果有10条并行的请求发送（复用一个channel），那么是每条请求超时是300ms吗？
问题的背景是我们自己搞了一个channel cache，同一个peer复用一个channel，进程启动就创建这个cache，直到进程退出销毁。但是发现有时候会报错Reached timeout，如果改为去掉channel cache，每次都重新创建channel就没有问题。所以想请教一下这里面的细节。

我看brpc的代码 `Channel::CallMethod`里面（v0.9.6），如果没有设置controller的timeout，则会用channel option的timeout覆盖controller的timeout。
```
void Channel::CallMethod(const google::protobuf::MethodDescriptor* method,
google::protobuf::RpcController* controller_base,
const google::protobuf::Message* request,
google::protobuf::Message* response,
google::protobuf::Closure* done) {
// ... 忽略中间代码
// Override some options if they haven't been set by Controller
if (cntl->timeout_ms() == UNSET_MAGIC_NUM) {
cntl->set_timeout_ms(_options.timeout_ms);
}
```

**To Reproduce (复现方法)**

**Expected behavior (期望行为)**

**Versions (各种版本)**
OS:
Compiler:
brpc:
protobuf:

**Additional context/screenshots (更多上下文/截图)**

Start with the official timeout documentation and Channel::CallMethod in brpc v0.9.6, focusing on how ChannelOptions.timeout_ms and Controller.set_timeout_ms are applied. Compare that behavior with the reported channel-cache and parallel-request scenario. Done means the timeout semantics are confirmed and the documentation clearly explains the per-RPC behavior.

Written by the indexing model from the issue text.