Currently, SERVER-101261 is looking into exercising the reopening pathway by fuzzing parameters in the config fuzzer suites. However, when looking at the collStats
we are missing coverage for re-opening for these following hard-closed reasons that we aren't able to induce using fuzzing:

1. kTimeForward
2. kTimeBackward
3. kSchemaChange

I think it would make sense to make a fsm_workload for each of these cases and then also making a fsm_workload that performs inserts of measurements that exercise all of these three reasons.

Note that for schema change, to induce reopening, we would want to insert measurements with one field that has different schemas from a choice of 2-3 schemas rather than always having distinct schemas.