Currently, a node can transition from rollback to removed state by being removed through a reconfig detected by the heartbeat processor before the rollback has actually completed. This caused a BF, fixed by SERVER-119090, where we did not account for the fact that this is a valid transition. This ticket is to do a deeper investigation into this edge case.

• Are there any other places where we assume that checking the rollback state is sufficient to know whether we are rolling back? If so, are we handling the possible transition to removed state correctly?
• Should this transition should be allowed, i.e., should we be allowed to transition out of rollback state while a rollback is still going on? It would simplify assumptions to tighten the association here, but a behavior change would cause side effects, as nodes would disagree about cluster membership for the duration of the rollback, which could take 45 minutes or longer. For example, the response to {hello}

  would be different between different nodes.

• During removed state, prior to SERVER-119090, journal flushing was still going on. Are there any other behaviors that are still happening while in REMOVED state that should be shut down?
• Should REMOVED state be a terminal state? That is, should we allow a node to be re-added to a cluster without being wiped and initial synced again?