storage,server: disable separated intents

[sumeerbhola]

They are disabled by default, and the setting is
not randomized on the testing path for testserver.go.

This was causing slowness in TestLogic/*/aggregate
resulting in TestLogic sometimes exceeding the
test timeout.

This is due to an unforseen slowness in intent
resolution caused by the effectively randomized ordering
of the latest and older intents.

Informs #41720

Release note: None

[cockroach-teamcity]

This change is 

[sumeerbhola]

TFTR!

[sumeerbhola]

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)

[nvanbenschoten]

This is due to an unforseen slowness in intent resolution caused by the effectively randomized ordering of the latest and older intents.

Could you explain this further? Is this due to the key encoding of LockTableKey, which uses a /strength/txnID key suffix that does not allow us to efficiently find a given key's lock table key? If so, I'm surprised this would be so pronounced. We haven't yet implemented soft lock-table resolution (finalized but not removed), so we should only have a single lock table key version at a time. So are LSM tombstones the issue? If so, do we have the option to perform more targetted seeks when performing point (i.e. not ranged) intent resolution, where we know the txn whose intents we want to resolve?

Do you have thoughts on mitigating this? I imagine we don't want to rethink the lock table key encoding to order by timestamp.

[sumeerbhola]

Yes, it's the LSM tombstones. When the intent resolution path also needs to read the latest version, the interleaved intents case would be as bad (or worse) since the pebble.Iterator.Next call would have to iterate over all the deleted ones. But the common path for committed intent resolution only needs to read the intent.
And yes, using the txn ID is exactly what I was planning to do for the single intent resolution path, but it doesn't help with range intent resolution.
I've opened #60622