Background: In WT-17323, we track the most recent write timestamp in every btree.  This is used by sweep to determine if the btree can be closed.  It's okay if this write timestamp is a little conservative, as it just means a btree that is idle might be closed a little bit later on average.

In an early version of the PR for WT-17323, I added a potential optimization that set the write timestamp to an exact second boundary (rounding up to the next exact second, so it is conservative).  It does mean that the btrees that suddenly become idle might be closed on average less than a second later.  The reason this is (potentially) an optimization if for customers that have one btree that dominates the workload, possibly with many writers.  Consider 1000 threads all doing updates on the same btree, they're all pretty much advancing the write timestamp for the btree, and they'll all do a CAS instruction on the same memory trying to advance the timestamp in a precise manner.  Presumably, there'll be a lot of collisions.  However, we don't know the effect of this, whether it even will show up as a perf hit for this kind of "worst case scenario".  The PR ended up having that optimization removed, since it's "premature", there's no evidence that it helps.

So this ticket is to investigate workloads that are effectively single-btree write heavy.  Do they exhibit this bottleneck (if so, there's an optimization buried in a branch commit stream)?  Or perhaps the workloads exhibit other bottlenecks that should be explored.  There is a certain class of customer that will care a lot about this.