GeezerVison

…eturns

`a_shutdown_ends_an_unbounded_commit_loop` now waits for `encode` to return before the 200 ms
pause that precedes its shutdown.

The test cancelled 200 ms after starting the committer thread, assuming the write had finished
by then. In a debug build on a busy test runner it had not, so the shutdown aborted the write
itself ("Delta table write aborted after 0 attempts: the pipeline is shutting down") and the test
failed at its check that the write succeeds.

The committer thread signals between `encode` and `batch_end`, so the shutdown lands in the
commit loop, which is what the test checks. Both calls still run on that thread, so a hang in
either fails the test rather than hanging the run.

Signed-off-by: Leonid Ryzhyk <[email protected]>

…ult wait

`delta_table_output_test` now waits up to `default_timeout_ms` (600 s, or `FELDERA_TEST_WAIT_MS`)
for its pipeline to complete, instead of 100 s, and its timeout says what it waited for.

The output proptests that call it draw up to 20,000 rows. In a debug build on a busy test runner,
an 18,620-row draw took longer than 100 s, and the case failed although the pipeline was only
slow.

The limit is the suites' default, the one `wait_for_records_materialized` uses, so a run that
lowers `FELDERA_TEST_WAIT_MS` shortens this wait as well.

Signed-off-by: Leonid Ryzhyk <[email protected]>

When an earlier read-ahead of the same block finished between the look in
the cache and the claim, the claim succeeded and the block was read a
second time.  This made
`a_walk_that_overtakes_its_read_ahead_waits_rather_than_reading_twice`
flaky.  `DataBlock::new` already looks again after its claim.

Signed-off-by: Leonid Ryzhyk <[email protected]>

…eader

Four of the five sat on `&*` of an `Arc<dyn FileReader>`, which the lint
does not flag.  The fifth covered a no-op reborrow of a `&dyn FileReader`
in `FileTrailer::new`, which now passes the reference itself.

Signed-off-by: Leonid Ryzhyk <[email protected]>