...and shard primaries should read the configOpTime and wait for it to become durable on stepup, before resuming coordinating commits.

Otherwise, a new coordinator primary might assume a participant shard has received the decision, even though it hasn't. Example:

1. Coordinator Primary 1 (P1) sends prepare to Shard A
2. Shard A enters prepare
3. P1 steps down, Coordinator Primary 2 (P2) resumes the coordination and refreshes its ShardRegistry from a stale config server which doesn't have Shard A
4. P2 gets ShardNotFound for Shard A and treats the ShardNotFound as an ack.
5. Shard A remains in prepare forever.

The suggested fix implementation is to:

1) make coordinators update the configOpTime in the minOpTimeRecovery document along with writing the participant list, here. (The coordinator then waits for writeConcern, which would cover both writes).

2) make the "recover pending commits on stepup" task load the persisted configOpTime into memory before waiting for writeConcern