GH-51547: [C++][R] Reopen IPC dataset reader asynchronously

[gitedmond]

Rationale for this change

Fixes #51547. The IPC dataset scan opens a reader asynchronously, then synchronously reopens it to apply projected fields. The synchronous reopen can wait for footer IO while a generator lock is held, creating the blocking cycle described in the issue.

What changes are included in this PR?

• Use the existing OpenReaderAsync path for the projected reader reopen.
• Add a controlled C++ regression test that gates the second reader’s footer read and checks that scan setup and a CPU worker can make progress before that read completes.

Are these changes tested?

• Before the fix, the new regression failed at the expected blocking assertion in 10/10 runs.
• After the fix, the identical regression passed in 100/100 runs.
• The other 34 tests in arrow-dataset-file-ipc-test passed.
• git diff --check and formatting of changed lines passed.

The reporter’s intermittent R workload was not reproduced here; this test isolates the blocking reader reopen that their stacks identified.

Are there any user-facing changes?

IPC dataset scans no longer block during the projected reader reopen. There is no public API change.

Was AI used for this PR?

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

AI assistance implemented the C++ change and regression test, inspected the code path, and ran the before/after tests. This draft is available for human review.

• GitHub Issue: [C++][R] Deadlock in IPC dataset scan with a small IO thread pool: synchronous reader re-open inside MergedGenerator lock #51547

[github-actions]

⚠️ GitHub issue #51547 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51547 has been automatically assigned in GitHub to PR creator.

[createcentury]

This looks correct to me, and the regression test is the part I'd highlight.

The fix. The deadlock in #51547 comes from reopen_reader calling the synchronous
OpenReader, which reaches RecordBatchFileReaderImpl::ReadFooter() — a blocking
ReadFooterAsync(nullptr).status(). Because MergedGenerator::State::PullSource() holds
the state mutex across the call into the source generator, that blocking wait happens
while the lock is held, and every completion callback that needs the same mutex is stuck
behind an IO read that can no longer be serviced. Switching to OpenReaderAsync removes
the wait entirely rather than making it less likely, so the lock is never held across an
IO round trip. The two overloads take the same arguments and reopen_reader already
returns Future<...>, so nothing else has to change — and the initial open a few lines
above already goes through OpenReaderAsync, so this just makes the re-open consistent
with it.

The test. GatedIpcBufferReader is a nice way to handle this. Rather than trying to
race the original deadlock, which would be inherently flaky, it holds the second open's
first ReadAsync as an unfinished Future and asserts that ScanBatchesAsync returns
while that IO is still outstanding. That tests the actual invariant the fix establishes —
no synchronous wait on the reopen path — and it fails deterministically if that invariant
is ever lost. Returning a different reader on the second open through the FileSource
factory lambda targets exactly the path in question, which is a detail that's easy to get
wrong.

CI is green across the board here — 43 passing, 16 skipped, nothing failing, including
ARM64 macOS 14 C++ and AMD64 Ubuntu 24.04 C++ ASAN UBSAN.

This has been sitting since September 28th without a review. Could a committer take a
look? The analysis in #51547 is unusually thorough and the fix that came out of it is a
one-line change.