The change in cockroachdb#21562 made it possible for queues to process replicas in
parallel. In doing so, it changed how `baseQueue` handled the queuing of
replicas that were already processing when `MaybeAdd` was called. This
was not an issue before because only a single replica could ever be
processed at a time, so it was not an issue to add the replica that was
currently processing back into the queue. That said, the previous approach
could result in replicas being queued with the wrong priority, which
could result in queuing inefficiencies.

With the changes made in cockroachdb#21562, `baseQueue` now needs to be careful that
the same replica doesn't get processed twice at the same time. This is
accomplished by using a `requeue` flag on the `replicaItem`. If the flag
is set when a replica finishes processing, we requeue it. This ensures
that we never skip a necessary processing attempt, and is safe because
all queue processing is idempotent.

This change makes sure that we call `ShouldQueue` again before placing
replicas with the `requeue` flag back in the queue. This isn't strictly
required for correctness (again, because processing is idempotent), but
it ensure that we don't add replicas back into the queue needlessly. It
also ensures that we place the replica back in the queue using the
priority provided by `ShouldQueue` *after* the earlier processing attempt
finishes, instead of the priority it had *before*. This fixes a subtle
issue that we've actually always had.

I suspect that this would have helped keep the queue size down in some
of the testing from cockroachdb#21562. It would have also helped us in keeping
the max range size down because we would have better optimized the
ranges that we prioritized when the queue began to fill.

Release note (performance improvement): Multiple ranges can now split at
the same time, improving our ability to handle hotspot workloads.