Settings defined in the FSM's data are initialized to their definition value when the FSM's processes are started, implying that any change applied in the setup function is lost. The proper way to rely on changes applied in the setup function phase is to avoid the initialization to their default when the FSM test is instantiate.

The random_DDL_operations.js test skips movePrimary operation when the non-resilient version is enabled, but the feature flag status is not propagate properly to the FSM's processes, causing the the non-resilient movePrimary to run.

The problem is relatively easy to occur on the 6.3 branch, but multi-version suites on master may trigger the same.