Resolved an issue where reading a file in chunks using an unbounded range would read from the current file pointer even for regular files.

Motivation:

When a FileChunks object is initialized, it checks if the range is set to 0..<Int.max. If it is, then instead of reading using a series of offsets and the pread sys call, it uses the read syscall repeatedly. This is fine if the read is the first ever of this type for a file, but if we read this way twice, then the second call will be affected by the side file pointer effect from the first call.

For example:

// Read the file the first time. This will repeatedly call `read` until EOF.
var firstRead = ByteBuffer()
for try await chunk in handle.readChunks(in: 0..<Int.max, chunkLength: .bytes(128)) {
  XCTAssertLessThanOrEqual(chunk.readableBytes, 128)
  firstRead.writeImmutableBuffer(chunk)
}
// Read the file again using `read` until EOF. This will read zero bytes since the previous call moved the file pointer to the end of the file without resetting it.
var secondRead = ByteBuffer()
for try await chunk in handle.readChunks(in: 0..<Int.max, chunkLength: .bytes(128)) {
  XCTAssertLessThanOrEqual(chunk.readableBytes, 128)
  secondRead.writeImmutableBuffer(chunk)
}

The main issue is that the read syscall affects the file pointer while the pread syscall does not.

Modifications:

• Add a readChunksFromFilePointer to ReadableFileHandleProtocol to explicitly read from the current file pointer instead of relying on the magic 0..<Int.max range.
• Use the new function when reading from an unseekable file in .readToEnd.
• Rename the ChunkRange cases to make what they are doing clearer.

Result:

Reading 0..<Int.max over and over again will have the same result each time.