SLS-1867 added an option to disable fsync for disaggregated storage, helpfully configured as the lose_all_my_data option.

There wasn't a follow-on change to actually use this option in MongoDB, since there were bigger fish to fry during the performance sprint.

However, the original observation that fsync is taking a meaningful proportion of checkpoint time (in disagg) still holds true. We should understand why this is, and stop doing that. It's possible that checkpoint is doing unnecessary work besides the fsync, that work is also in scope.

A successful outcome here would be to ensure that local IO for checkpoints in disaggregated storage doesn't generate meaningful overhead. (It's OK to have some content written locally, but that mustn't be slow.)