Readonly transactions are ~4 times slower than expected

(Write transactions are also slower, but focusing on readonly transactions for now.)

We've had a user complaint that readonly transactions are significantly slower than expected, and initial performance testing is supporting that.  A transaction doing a single transactional KV get should be around the same performance as doing a non-transactional KV full-document read.  The transaction won't be creating an ATR (only done on mutations) or committing anything, and it should just be looking up the document using a KV sub-doc read.  It'll only take longer if that document is in the middle of another transaction and a MAV read needs to be performed.

However in perf testing we see such readonly transactions take ~4 longer than the roughly equivalent KV lookups.

With 1 load-generating thread it's taking 221 microseconds to complete a read-only transaction on average (p99=295 and max=1707). 

With 20 threads it's taking 931 micros (p99=1276 max=9271).

But with regular KV full-document fetches - which we'd expect to take about the same amount of time - with 20 threads it's taking ~219 micros on average (p99=264, max=675).

So 219 micros vs 931, 4.25x slower on average.

Java results

I ran the same perf test with Java, and see similar issues.

I've begun investigation on JCBC-2085.  It's too early to be sure but early results suggest the slowness there is coming from a mixture of a) UUID creation b) just creating a ton of objects and c) some inefficiencies, e.g. at least one of the bottlenecks is involving creating an object on every transaction that could instead be reused.  Apart from the UUIDs I'm not seeing much that will transfer to C++, and though they are both slower than expected this is, I currently think, a coincidence.