The backup-restore fixture may kill its FSM client while the latter is in the process of dropping the test database as part of its per-workload cleanup. In that case, that fixture could later fail to write to that database, as it may be in a drop-pending state. The following improvements can be made to avoid this scenario:
1. Use an assert.soon to poll for the test database to no longer exist right after killing the FSM and CRUD clients. (We currently all ReplSetTest.awaitReplication(), which is not sufficient in this case, since the drop database oplog entry may not exist yet).
2. The backup-restore fixture attempts to ensure replication between workloads by doing a w:3 insert on the test.fsm_teardown collection and then immediately dropping it. It would be more useful to change the write concern to w:majority so that we can be sure it gets committed.