It was pretty confusing to me at first. It still
is somewhat confusing, but at least now it's
also somewhat documented.

Also, conditionally skip two tests based on it, as these tests will surely break
with any change to the reproposal internals.

Epic: none
Release note: none

This will be set from code that is yet to be written to address
undefined/possibly data-racy access to ProposalData. We haven't seen issues
with this in practice, but since ProposalData may exist outside of the
proposals map during log application and it will be accessed and mutated
without replicaMu while *also* being reinserted into the proposals map, I don't
see any reason why data races wouldn't be possible. We're probably just getting
lucky today.

This paves the road to not having to rely on luck in the future.

The first part is annoying because it `return nil` in cases where V2 would just
want to error out. To avoid this branching between v1 and v2 to become too
spaghetti, split the "bad" from the "good".

retrieveLocalProposalsV2 is used with useReproposalsV2, replacing a call to
retrieveLocalProposals. The V2 implementation is simpler because a log entry
that comes up for a local proposal can always consume that proposal from the map
because V2 never mutates the MaxLeaseIndex for the same proposal. In contrast,
with V1, we can only remove the proposal from the map once we have found a log
entry that had a matching MaxLeaseIndex. This lead to the complexity of having
multiple entries associated to the same proposal during application.

With this, we're in a position to actually enable `useReproposalsV2`: we now
repropose as a "new" proposal.

The process of "forking" a proposal into a new proposal is still too manual and
there is little focused testing coverage. However, adding such coverage likely
incurs many refactors. So instead here the approach is to make minimal changes
and rely on randomized coverage via
`TestProposalsWithInjectedLeaseIndexAndReproposalError` to weed out "obvious"
issues and have some confidence that the changes "work" at least most of the
time.

At that point we can commit to moving forward with V2 and start simplifying the
code, which also allows adding more targeted testing (though this will still be
challenging as some of the invariants we'd like to test are quite subtle and
spread out).

…tCommand

When a field is added to these, two places need to be updated - the main
proposal path and tryReproposeWithNewLeaseIndex{,v2}. This commit adds a
test that will explicitly need to be updated when such a field is added.

Epic: none
Release note: None