sql/kv: resetForNewSQLTxn is inefficient and allocation heavy

[nvb]

resetForNewSQLTxn is full of low hanging fruit that is ready to be plucked. I've repeatedly observed the function come up in benchmarks. Currently I'm seeing it account for 4.59% of CPU utilization and 9.15% of total allocated memory in sysbench's oltp_point_select workload. If #32427 (comment) is any indication, there's a big win sitting here.

The two biggest offenders in the function are client.NewTxn and tracing.StartRootSpan. The former adds more weight behind the argument that we need to start pooling client.Txn and especially kv.TxnCoordSender objects. I don't know much about the latter, other than that I've talked to @andreimatei about this before and I remember we we're doing something strange with tracing even when it's not enabled just so that we could enable it mid-transaction. We should fix that.

cc. @andreimatei @jordanlewis

Jira issue: CRDB-4741

[andreimatei]

I think I had some improvements for StartRootSpan sitting somewhere. Will get back to them when I can.

[knz]

@jordanlewis @petermattis in which project should this issue land, in your opinion?

[petermattis]

Similar to #32427, I think this should land in SQL Execution for want of a better place.

[andreimatei]

I have something cooking for the span creation and also something tangentially related for moving towards pooling different txn-related KV objects (around #30773).