incr-join, find_updates: avoid unncecessary clones & use partition

[Centril]

Description of Changes

First commit: Only clone once per TableOp in find_ops, achieved using Iterator::partition:

Benchmarking incr-join: Collecting 100 samples in estimated 5.
incr-join               time:   [2.9260 µs 2.9296 µs 2.9334 µs]
                        change: [-5.7704% -5.0041% -4.4248%] (p = 0.00 < 0.05)
                        Performance has improved.

Second commit: Clone even less and have JoinSide hold Vec<PV> instead:

Benchmarking incr-join: Collecting 100 samples in estimated 5.
incr-join               time:   [2.5716 µs 2.5786 µs 2.5901 µs]
                        change: [-17.024% -16.337% -15.765%] (p = 0.00 < 0.05)
                        Performance has improved.

All numbers are vs. master baseline.
(i7-7700K, 64GB RAM)

API and ABI breaking changes

None

Expected complexity level and risk

1

Testing

No semantic changes.

[gefjon]

Beautiful. The unnecessary clones in this code path have been bugging me for a while. Thanks for getting rid of them!

Minor comment-related crap, plus a question about reborrowing.

[gefjon]

What's up with the reborrows on line 343? Why can't this be

let partition_into = |ds: &mut Vec<_>, is: &mut Vec<_>, updates: &DatabaseTableUpdate| {
  for update in &updates.ops {
    if update.op_type == 0 { ds } else { is }.push(update.row.clone());
  }
};

[gefjon]

Also, ugh, I hate all these 0s and 1s. If I get some spare time, I'll make a follow-up that defines constants OP_TYPE_DELETE and OP_TYPE_INSERT (assuming we don't have those already...).

[Centril]

So the reborrow here is due to the compiler failing to insert a reborrowing coercion on its own, apparently due to interactions with generic code. It's rather obscure, but this is the best I could find, rust-lang/rust#62112.

Addressed