Simplify the iterator adaptive splitting strategy

Before, when an iterator job was stolen, we would reset the split count
all the way back to `current_num_threads` to adaptively split jobs more
aggressively when threads seem to need more work. This ends up splitting
a lot farther than a lot of people expect, especially in the tail end of
a computation when threads are fighting over what's left. Excess
splitting can also be harmful for things like `fold` or `map_with` that
want to share state as much as possible.

We can get a much lazier "adaptive" effect by just not updating the
split count when we split a stolen job, effectively giving it only _one_
extra boost of splitting.

Author: cuviper

src/iter/plumbing/mod.rs

@@ -273,9 +273,8 @@ impl Splitter {
         let Splitter { splits } = *self;
 
         if stolen {
-            // This job was stolen!  Reset the number of desired splits to the
-            // thread count, if that's more than we had remaining anyway.
-            self.splits = cmp::max(crate::current_num_threads(), self.splits / 2);
+            // This job was stolen! Leave the `splits` count alone while we go ahead and split
+            // anyway, so we dynamically get more splitting for jobs that are moving a lot.
             true
         } else if splits > 0 {
             // We have splits remaining, make it so.