FSM threads race in secondary_reads_with_catalog_changes.js

In this test, after SERVER-50610, the logic is roughly:

• thread 0 always does inserts (with implicit createCollection) and create index on field x
• All other threads do one of dropIndex, dropCollection, or scan index x (retry if index x not there because we assume thread 0 will create an index eventually)

However, if thread 0 completes before others, all other threads could hang if the index is dropped again after.

I think maybe we could make the dropIndex thread to always recreate one after dropping the index so we don't rely on tid:0 being there to create the index. In other words, we probably should never have dependencies between threads in FSM because some of them might finish before others.