I have an experimental branch which I'm probably not going to get to anytime soon, so I wanted to at least put the idea out there to see if there are any takers.

The closed timestamp target duration is currently set high (30s) because transactions running longer than the target duration tend to get disrupted. If we set, say, a target duration of 1s, a transaction that takes two seconds would never be able to finish (unless it got to refresh its way to a commit).

The idea in the WIP is to make the closed timestamp target duration receptive to when it forces a transaction to restart. For example, if the target duration is 1s normally, and a transaction is forced to restart because its timestamp is below the recent closed timestamp, this will cause the target duration to temporarily double (or whatever) to 2s. If this is not enough, it will double again, etc, until the "slow" transaction can commit.

It's completely unclear to me whether this can be productionized and how low we can comfortably set the closed timestamp after, but it seems worth looking at as a strategy to automatically converge to a closed timestamp duration that's "usually" not in the way of ongoing requests while at the same time allowing the occasional slow request to finish, too.

The heuristics in the WIP are not great and it's not even using the right input data (we should pass txn.OrigTimestamp to RequestBackoff, if that is even good enough).