db: experiments to improve WAL sync latency and reduce overhead

See detailed discussion in https://cockroachlabs.slack.com/archives/CAC6K3SLU/p1753466425379189 and the docs linked there.

Summary: ext4 fdatasync flushes everything in the current metadata transaction, including unrelated file writes. In Pebble, we do frequent calls to fdatasync when doing WAL writes, and infrequent fsyncs in compactions and flushes. The WAL write syncs are latency sensitive. With the upcoming separation of the Raft log and the State machine engines, the latter won't have a WAL, and it would be even more desirable to only flush the data in the former WAL with a fdatasync. It is also possible that this could reduce write IOPS by not prematurely flushing unrelated changes.

XFS fdatasync only flushes data for the relevant file. @RaduBerinde also suggested putting the WAL on a separate partition on the same disk.

From @RaduBerinde: TODO: run some kv0 experiments with ext4/xfs and with/without separate WAL partition

Jira issue: PEBBLE-1115