Fix server IO->CPU dispatch so rpc_num_cpu_worker_threads > 1 works (#749)

[charles-typ]

Summary:

Setting rpc_num_cpu_worker_threads > 1 made the server go completely idle (~2% CPU, requests never processed) during a benchmark, so the flag was unusable and the prod-like "IO -> CPU -> IO" dispatch pattern it is meant to exercise never actually ran.

Root cause: the Thrift handlers are async_eb_*, so they must complete their HandlerCallback on the callback's own EventBase. ucacheBenchOnRequestCommon offloaded work to a folly::CPUThreadPoolExecutor (from getCpuPool(), only created when the flag is > 1) and then invoked the handler — which called cb->result(...) — directly on the CPU-pool thread. Those pool threads are not EventBase threads and are unknown to the per-EventBase handler map, so the reply was never delivered. In-flight requests never drained, clients stopped sending, and the server sat idle. With the flag == 1, getCpuPool() returns nullptr, everything runs inline on the IO thread, and it works — which is why the bug only showed up for > 1.

Fix: split compute from delivery. The per-request handler now COMPUTES and returns the reply; ucacheBenchOnRequestCommon owns delivering it via callback->result(...). On the CPU-pool path it captures the callback's EventBase up front, runs the compute on the pool, then bounces the completion back with evb->runInEventBaseThread(...) so the async_eb callback is completed on its own EventBase. The inline and fiber paths are behaviorally unchanged for the default rpc_num_cpu_worker_threads == 1.

Verified: with the fix, rpc_num_cpu_worker_threads=64 drives real traffic and the run completes cleanly ("All clients finished benchmark"), where before it hung the server at ~2% CPU. Note: the dispatch path trades throughput for the extra IO->CPU->IO context switches (as intended, to match production's tao:slow scheduling); it is a fidelity knob, not a throughput/utilization lever.

Reviewed By: excelle08

Differential Revision: D110506501

[meta-codesync]

@charles-typ has exported this pull request. If you are a Meta employee, you can view the originating Diff in D110506501.