This commit reduces the likelihood of the following situation:

* A large transaction (e.g., backfill) produces a large output batch, say
  1B records. This batch consists of `workers` spines, each with potentially dozens
  of batches.
* These batches are pushed into a single spine inside the output buffer. Once
  the number of batches in the spine exceeds 128, backpressure kicks in. We've
  seen pipelines with 32 workers spend >1hr waiting for backpressure.

We address this in two ways. First we insert all batches into the spine before
waiting for backpressure. This is likely to trigger fewer larger merges. Second
we postpone checking for backpressure until additional batches retrieved from the
output queue are added to the buffer. This avoids waiting for the merger when the
buffer is large enough to be sent to the connector.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

In the past, if the user set max_output_buffer_time_millis, but not
max_output_buffer_size_records, then the output buffer would hold data
for the specified duration regardless of its size. The user was required
to also configure max_output_buffer_size_records to force a large buffer
to be sent immediately.

The downside of not setting max_output_buffer_size_records is that
quickly adding more batches to an already large output buffer could
cause expensive backpressure stalls.

This commit changes the default to 10,000,000 records, meaning that once
the buffer reaches this size it will be send immediately.

The purpose of the output buffer is to avoid the small file problem for
connectors such as Delta. In this type of use case, waiting for exactly
max_output_buffer_time_millis is not a hard requirement, so the new
default should be harmless. However it is a behavioral change, which
I documented in the changelog.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

Signed-off-by: feldera-bot <feldera-bot@feldera.com>