worker线程全部卡住时主动拒绝请求

最简单的“卡住”方式就是usleep或sleep（但不是bthread_usleep，并不会卡住worker）。当所有的worker都陷入sleep时，EventDispatcher也不会工作，直到某个worker醒来，相应的请求会被延迟，但server端无法感知到这点，因为请求处理的“起点”就是EventDispatcher中的epoll，它同样被延迟了。可能的改进有：
1. 让EventDispatcher运行在独立的pthread中，就像TimerThread那样，可能会略微降低新请求的调度。这个改进的问题在于brpc中的epoll和读取在不同的线程，epoll一次醒来后只要连接中有数据，读取线程就会持续读，这可能会导致epoll醒来的时间明显早于请求到达的时间，使延时计算不准确。
2. 当发现worker不足时自动增加worker。百度内的分支做过类似的改动。但这和不支持动态创建tls的server会有冲突。新增的worker中的tls可能为空导致应用错误。
3. 在bthread层面能汇报worker是否用满，brpc中发现用满也返回ELIMIT。比较倾向于这个方式，这个机制还能统一usercode_in_pthread模式中的一些代码。

Start by reading brpc's EventDispatcher and bthread worker-exhaustion behavior, then compare the TimerThread and usercode_in_pthread paths mentioned in the issue. The issue names no files or tests and presents three competing designs, so a contributor must first establish the intended approach. Done means an agreed design reliably handles requests when all workers are blocked without breaking TLS or latency semantics.

Written by the indexing model from the issue text.