This is one of the few places in the protocol where we have a single
RPC that results in two distinct actions:

- 1) Downloads the new log segment data (above)
- 2) Records the new Paxos data about the synchronized segment (below)

These need to be treated as a transaction from the perspective
of any external process. We do this by treating the persistPaxosData()
success as the \"commit\" of an atomic transaction. If we fail before
this point, the downloaded edit log will only exist at a temporary
path, and thus not change any externally visible state. If we fail
after this point, then any future prepareRecovery() call will see
the Paxos data, and by calling completeHalfDoneAcceptRecovery() will
roll forward the rename of the referenced log file.

See also: HDFS-3955

The fault points here are exercised by the randomized fault injection
test case to ensure that this atomic \"transaction\" operates correctly.