This change reworks how RESTORE splits and scatter's in 2 ways:

1.
This commits updates the split and scatter mechanism that restore uses
to split at the key of the next chunk/entry rather than at the current
chunk/entry.

This resolves a long-standing TODO that updates the split and scattering
of RESTORE to perform a split at the key of the next chunk/entry.
Previously, we would split at a the start key of the span, and then
scatter that span.

Consider a chunk with entries that we want to split and scatter. If we
split at the start of each entry and scatter the entry we just split off
(the right hand side of the split), we'll be continuously scattering the
suffix keyspace of the chunk. It's preferrable to split out a prefix
first (by splitting at the key of the next chunk) and scattering the
prefix.

We additionally refactor the split and scatter processor interface and
stop scattering the individual entries, but rather just split them.

2.
Individual entries are no longer scattered. They used to be scattered
with the randomizeLeases option set to false, but there was not any
indication that this was beneficial to performance, so it was removed
for simplicity.

Release note: None

This change fixes a bug in the planning of the restore DistSQL flow. The
ordering of the source router slots did not match the order that the
streams were added to the range router. This meant that the range router
could mis-direct rows in the flow to the incorrect node.

Ever after this change, it appears that a lot of AddSSTables are not
handled locally and so the release note does not indicate any
performance improvement.

Release note: None

This change updates the chunk size to take larger clusters into account.
On larger clusters, having more chunks (that are each smaller) is
beneficial because this results in more even load after scattering these
chunks.

Release note: None