storage: reproposals generated after range creation

[andreimatei]

We've discovered in #33453 that reproposals are quite likely after a range is created because the first message that pops out of Raft is an empty message indicating a leadership change, and that causes every other pending proposal to be re-proposed. Some of these reproposals are unnecessary, as the proposals would have made it to the right leader just fine.
We've speculated that this might be a significant slowdown for restores, which propose large commands immediately after ranges are created.
We should find a way to improve things - perhaps not re-proposing too eagerly or not re-proposing large messages when the reproposal reason is "new leader".

cc @bdarnell in case you've got an opinion

Jira issue: CRDB-4687

[bdarnell]

We need to be careful with this. A new range goes through a couple of transitions. Initially, it has no leader (raft.lead = None). During this state it simply drops any proposals on the floor; these proposals must be reproposed once the new leader is established (that's why this reproposal trigger exists). After the leader election, raft.lead != None and the new leader proposes its empty entry. Commands submitted during this phase are the ones you're concerned about here - they will be queued up behind the empty entry and will almost certainly commit without being reproposed.

To distinguish the two cases, we need ErrProposalDropped: #21849 A proposal that returns ErrProposalDropped should be retried on the next reproposal trigger. A proposal that does not experience this error can be retried less aggressively (I'm not sure at the moment exactly what rules should apply)

[github-actions]

We have marked this issue as stale because it has been inactive for
18 months. If this issue is still relevant, removing the stale label
or adding a comment will keep it active. Otherwise, we'll close it in
10 days to keep the issue queue tidy. Thank you for your contribution
to CockroachDB!