kv: remove ShouldWinOriginTimestampTie option fromcput

[jeffswenson]

The current KV writer does not use ShouldWinOriginTimestampTie, so it can be removed as unused code. The KV LDR writer stopped using this approach for tie-breaking due to two issues:

1. When replaying replicated writes, they win LWW against themselves, leading to duplicate KVs. This is inefficient, slowing performance and wasting storage until garbage collection (GC) removes the duplicates.
2. The approach fails to handle semantics correctly in three-way replication scenarios.

Release note: none
Epic: CRDB-48647

[cockroach-teamcity]

This change is 

[stevendanna]

👍 on just removing this until we can think through how we want to handle ties in the 3-way replication case a bit more.

I wonder if ties are more common on macOS where we don't have nanosecond-precise timestamps.

[jeffswenson]

Thanks for the review!

👍 on just removing this until we can think through how we want to handle ties in the 3-way replication case a bit more.

The way I think we should handle this is to pick unique replication cluster ids for each LDR peer (instead of 1 == remote). Then LDR would supply the ID of the local cluster and the replicating cluster. The only adjustment we need for tie handling is a cluster should lose ties against itself to avoid writing a row multiple times.

An alternative strategy is we could make the value encoding canonical and use the value to break ties. This would also make the cput based optimizations more efficient.

bors r+

[craig]

Build succeeded:

• docker_image_amd64
• examples_orms
• unit_tests
• lint
• linux_amd64_fips_build
• local_roachtest_fips
• acceptance
• check_generated_code
• linux_amd64_build
• local_roachtest