Alter logic for yielding from halfjoin

[frankmcsherry]

This PR changes the optimistically aggressive 10ms yield time for HalfJoin to a more conservative 1M records, which ensures that at least some amount of work gets done, at the expense of potentially stalling for longer. This has the potential to mitigate some "spinning" behavior that folks are seeing with this operator.

It is also possible that there is just a bug in the HalfJoin implementation, rather than the yielding policy. At the moment we don't have a reproduction of this issue, so it is hard to know. This PR is meant to be something they can use to test.

fixes MaterializeInc/database-issues#2699

[frankmcsherry]

This reportedly fixes the issue for at least one instance of 100% spinning with no progress.

Some more diagnosis: the removed 10ms yielding policy has the defect that it (due to the half join implementation) will yield after an initial consolidate of the work to do, and if that work takes 10ms or more will result in no work being done. That consolidation .. shouldn't need to be expensive once things are sorted, but you still need to go and do a whole bunch of memory dereferences to confirm everything.

The issue could also be ameliorated in the half_join implementation by stashing consolidated data in a representation that makes it clear that it has been consolidated (e.g. an enum), which had no value when we wouldn't revisit that work, but now makes sense if we will repeatedly yield and revisit the work (consider 1B inbound records; reviewing them each time we pluck off 1M work items means a massive amount of redundant work).

[frankmcsherry]

Merging with permission from @philip-stoev. Follow-up work on introducing tests to the nightly stress tests to look for this sort of issue, and others like it.