This bug was found by running with
IMPALA-4703 with the minimum possible reservation. The scenario is:
1. Processing of the last output build partition finishes (in OutputUnmatchedBuild())
2. Memory from that partition is attached to the output batch, bringing it to capacity.
3. Execution continues, with more memory allocated in PrepareSpilledPartitionForProbe()
The bug is that we should be flushing all memory before moving onto the next spilled partition - the code for processing a new spilled partition assumes that all of the reserved buffers are available.