Fixes cockroachdb#66682.

In cockroachdb#66682, we noticed a poor interaction between Raft and the MVCC API.
When a Raft leader is catching up its followers, it often sends out
large chunks of log entries. We prevent this from being overly expensive
in the presence of large log entries by limiting the aggregate size of
these entries to 32 KB (`defaultRaftMaxSizePerMsg`) at a time. This is
accomplished through the through the `maxBytes` param that is passed
throughout the `raft.Storage` implementation.

What we noticed was that even though we configure a `maxBytes` of 32 KB,
no limit is passed through to `iterateEntries`'s call to `MVCCIterate`.
This seems harmless enough, because the iterator function passed to
`MVCCIterate` terminates once the byte limit is exceeded. However,
behind the scenes, `MVCCIterate` pulls in up to 1000 entries
(`maxKeysPerScan`) from Pebble at a time, with no accompanying byte
limit. So in a cluster with large log entries, where even just one is
enough to exceed our budget, this ends up being very expensive.

In the customer cluster that we were looking at when we found cockroachdb#66682,
each log entry was 131KB large. So each attempt to grab a new log entry
read 131MB from the LSM. This was likely all cached, but even just
unmarshaling this was expensive due to the memory copies doing so
performs. This was so expensive that each call to grab a single entry
took about 65ms. This was bad, and it became even worse when a follower
sent 100 MsgAppResps in response to the 100 MsgApps sent by the leader
(which is suboptimal but expected). If these all landed on the leader at
once, it would spend `100*65ms = 6.5s` processing messages in
`Store.processRequestQueue`. This stall was long enough for another
follower to call an election and for the leader to lose its leadership.
Since two replicas were possible leaders and both were in this
situation, it never resolved and leadership ping-ponged.

This commit fixes this issue by replacing the call to `MVCCIterate` in
`iterateEntries` with direct use of an MVCC iterator. This provides more
control over iteration and allows us to avoid the unwanted readahead
policy. It also allows us to avoid some of the unnecessary cruft of
`MVCCIterate`.

_### Rejected Alternatives

I briefly considered trying to adapt `MVCCIterate` to be more
configurable through the `MVCCScanOptions` it is provided, but that
seemed like a fraught task. This was primarily because the `TargetBytes`
config is not quite what we want in this case, where we need to be
precise about the sizes of these entries (see 9d46451) and don't want to
count the key size of the MVCCMetadata wrapper size.

I also considered simply adding some conservative, non-configurable
readahead byte limit to `MVCCIterate` to sit alongside its key limit.
This may still be a good idea. But I also think we may want to restrict
the cases where we even use the function.

Finally, I considered removing the readahead behavior in `MVCCIterate`
entirely. I think it might have been added to avoid repeat CGo hops back
when we had RocksDB. But now that we have Pebble and can manipulate an
iterator cheaply, it can maybe be rejected. However, this would then
require us to lift some logic from `pebbleMVCCScanner` into
`MVCCIterate`, which I wasn't keen on doing.

Release note (bug fix): Catching up Raft followers on the Raft log is
now more efficient in the presence of many large Raft log entries. This
helps avoid situations where Raft leaders struggle to retain leadership
while catching up their followers.