Remove unsafe asynchronous close() call from FileDownloadChannel

Spark's Netty-based file transfer code contains an asynchronous IO bug which may lead to incorrect query results.

At a high-level, the problem is that an unsafe asynchronous `close()` of a pipe's source channel creates a race condition where file transfer code closes a file descriptor then attempts to read from it. If the closed file descriptor's number has been reused by an `open()` call then this invalid read may cause unrelated file operations to return incorrect results due to reading different data than intended.

I have a small, surgical fix for this bug and will submit a PR with more description on the specific race condition / underlying bug.