When the vector clock needs to be persisted by a secondary, waitForDurable ends up calling _vectorClockPersist on the primary and blocks waiting for the reply. However, if the same node steps up right before performing the call, there will be a deadlock because waitForDurable will wait on its own reply.

Thanks to the timeout, the system doesn't hang forever but the vector clock is not persisted and casual consistency is therefore not ensured.

Moreover, VectorClockPersistCommand::supportsWriteConcern is currently true, meaning that the command is required to be invoked with a write concern field, however it should be set to false because:
1) It is not necessary, because the VectorClockDocument is always written with majority write concern.
2) It is wrong, because the command fails on this uassert since requests are always received from internal clients (always from secondaries).