Async apis for NonBlockingFileIO

[adam-fowler]

Provide async versions of most NonBlockingFileIO APIs. This PR provides versions of all functions apart from the readChunked function which should probably be replaced by an AsyncSequence.

Some of the code running on the NIOThreadPool that would have been duplicated has been broken out into separate functions so it can be used by both ELF and async functions.

I've also provided async versions of the relevant tests

[adam-fowler]

I think it is complaining because I've reduced the number of allocations for the readChunked integration test.

EDIT: I reduced MAX_ALLOCS_ALLOWED_read_10000_chunks_from_file to get integration tests working

[adam-fowler]

I just saw #2578 which may clash with this PR as. I am passing NIOFileHandle across concurrency contexts. How should I proceed? I have used an @unchecked Sendable type to pass a FileRegion from the openFile operation. In this situation is it considered ok?

[FranzBusch]

NIOFileHandle can definitely not become Sendable since they must be owned by a single isolation region at any given time. However, with the new region based isolation pitch a lot of the cases where you currently want NIOFileHandle to be Sendable should be solved.

[adam-fowler]

Oh I know it shouldn't be Sendable. But what about the situation this PR covers where it is created on a NIOThreadPool and immediately passed back to a Task.

[dnadoba]

@adam-fowler You will need to use UnsafeTransfer in your implementation for this until we get region based isolation. You will need to copy the implementation over to NIOPosix as it is not public (and we don't want it to be public).

[adam-fowler]

Any chance of a review here?

[FranzBusch]

In general this looks good to me. I would like @glbrntt to also take a look since he spent some time with file systems recently.

[glbrntt]

This looks great, left couple of comments.

[FranzBusch]

Some last comments but looks really good

[glbrntt]

This is looks great, I left a couple of nits though.

[glbrntt]

LGTM!

[dnadoba]

We are planning to cut a release in the next couple hours. Let's wait til we merge this until then.

[dnadoba]

If you feel fancy you could also change the byteCount parameter types from Int to Int64 and temporarily throw an error if the value doesn't fit exactly into an Int (i.e. Int(exactly: byteCount) returns nil) until we convert the underlying APIs to also take Int64. More infos in this issue comment: #2591 (comment)
It would be quite easy as we don't need to deprecate any API as the async API is new.

Note that I'm not suggesting to fix the 4GB Buffer overflow issue, just the type change from Int to Int64.
This can also be done in a separate PR and doesn't block this PR from being merged.

[dnadoba]

NIO 2.62.0 released

[adam-fowler]

If you feel fancy you could also change the byteCount parameter types from Int to Int64 and temporarily throw an error if the value doesn't fit exactly into an Int (i.e. Int(exactly: byteCount) returns nil) until we convert the underlying APIs to also take Int64. More infos in this issue comment: #2591 (comment)
It would be quite easy as we don't need to deprecate any API as the async API is new.

@dnadoba I can add this. One minor issue though NonBlockingFileIO.Error is an enum which I can't extend. I'd have to add another error type. It might be better to deal with this in a separate PR which doesn't require the error because 64 bit read sizes will be supported.

[dnadoba]

Sure, we can just use a specific error that we later deprecate as this should only be a temporary issue I guess.