rpc: investigate regression caused by #138368

[tbg]

See #138368 (comment).

The PR causes a >1% regression (in latency) in BenchmarkSysbench/oltp_read_write. A first cursory investigation did not yield why, and allocations seem identical. We want to understand and fix this regression.

Epic: CRDB-42584

Jira issue: CRDB-46476

[RaduBerinde]

I tried inlining batchStreamImpl and doing away with the func and intermediary interfaces, I tried commenting out the drpc-related code in the dialer, and I could not reliably produce an improvement. I looked at profiles but couldn't find any of the changed code being responsible for anything signficant. It is possible that it's just due to importing a new library and having more code (and perhaps realigning certain hot code blocks w.r.t cachelines - something PGO in go1.23 is supposed to help with). I will try again looking at exactly the merge commit and the parent one and perhaps importing the change piece by piece.

Unrelated, but I did notice that according to the profile, shouldUseBatchStreamPoolClient takes about 0.5% and we should improve that:

[RaduBerinde]

It's hard to get accurate results since the difference is less than the usual standard deviation. But I think reverting all the client-side code gets part of it back (maybe 0.2-0.3%) - probably just a handful of otherwise insignificant changes. Even after reverting most server-side code I still see some regression. I will stop spending time on this now :)

[tbg]

This regression did not reproduce consistently. We thus suspect it's due to build effects, and not something we currently try to control for.