storage: evaluate proposals without lock

The main objective of this change is to (later) enable proposer-evaluated KV to
compute the `WriteBatch` when evaluating a proposal (i.e. when turning
a `BatchRequest` into a `*ProposalData`). The previous code assumes making
a proposal is cheap, and thus it is done under large critical sections,
encompassing in particular the command reproposal and refurbishment logic.

Unwinding the latter makes this change relatively subtle and it should receive
the appropriate scrutiny. In particular,

- externally-triggered proposal refreshal (such as after election or
  periodically) is now queued with the scheduler and then executed by it.
  This was necessary since the goroutines requesting the refresh should not
  be blocked by (potentially extensive) disk I/O.
- similarly, refurbishments during command application were offloaded, but
  to a goroutine.
- MaxLeaseIndex is assigned at the latest possible moment before submitting
  to Raft. Multiple inbound requests can pass the command queue without
  interacting, and previous code wasn't doing a thorough job at making it more
  likely that these proposals would submit to Raft in the order they underwent
  the lease index assignment, which wasn't necessary due to it happening in a
  large critical section. Now that this critical section has split, this had
  to move.

An alternative, namely bubbling refurbishment up to the client's done channel
(which would then have to repropose it as a completely new command) was not
considered, but may be preferrable in the long run.

At the time of writing, this change is WIP and depends on yet-unmerged #10004.
To allow reviewing, this PR was opened against a branch containing that PR.