Avoid readers acquiring GPU on next batch query if not first batch

[jlowe]

The readers all had logic that would unconditionally try to acquire the GPU semaphore in their hasNext() or equivalent predicate method to cover the case where a downstream exec would generate GPU data even when there were no batches from the reader (e.g.: reduction-only aggregations will produce a single row even with no input). This unconditional acquisition was great for covering that case, but it also can lead to poor performance where the following sequence can occur:

• First and only batch flows through task iterators and is eventually partitioned by shuffle logic
• Shuffle logic releases GPU semaphore
• Iterator chain is queried to see if there's another batch
• Reader iterator at end of chain always grabs the semaphore even when there's no more batches
• Task proceeds to wait for the semphore then exits without further work, preventing the current CPU core from working on the next task

This behavior can be seen in the following Nsight profile screenshot, where the second GPU acquisition is unnecessary:

This PR changes the logic so the GPU semaphore is only acquired by the reader iterator logic if this is querying for the very first batch. Once any other batch has been produced by the iterator, the empty input case no longer applies and the semaphore does not need to be acquired to cover it.

[jlowe]

build

[abellina]

@jlowe looks like some conflicts with GpuOrcScan

[jlowe]

build