SystemNative_CopyFile() should use copy_file_range() in Linux

[lpereira]

copy_file_range() is a relatively new syscall in Linux (4.5+, with a userspace emulation in glibc since 2.27) that copies data between file descriptors without passing them through userland. The kernel tries different methods depending on the filesystem (for instance, NFS supports a "cloning" operation that won't require data to go back and forth through the network, and that's tried first), ultimately performing a copy using splice().

On systems where this is supported, this should be used to implement file copying.

[jkotas]

CopyFileA/W is simulating Windows APIs of the same name and it is not used on any interesting path in CoreCLR. It is not worth the effort to improve it. It would be better to delete it.

The more interesting one to optimize is this one:
https://github.com/dotnet/corefx/blob/42ecf717478504fd7cc072f3586c6edd1ba57daa/src/Native/Unix/System.Native/pal_io.c#L1186 . This is used to implement File.Copy that gets a ton more usage.

[lpereira]

Ah, thanks. That function looks promising; it's already using sendfile(2), which isn't bad -- and end up being the fallback case for copy_file_range(2) when all methods it uses fail (sendfile(2) is essentially just a call to splice(2) with an implicit pipe).

There's a bug in there, too: if sendfile(2) was able to copy a portion of a file but returns some kind of error that's not EINTR, Copy_ReadWrite() is still called, copying everything from the start again, possibly hitting the same error. This could be an issue on networked drives.

Adding this to the backlog.