make vn_generic_copy_file_range() run efficiently when the input file has a large hole to EOF

[rmacklem]

Summary

PR#255523 reported that a file copy for a file with a large hole
to EOF on ZFS ran slowly over NFSv4.2.
The problem was that vn_generic_copy_file_range() would
loop around reading the hole's data and then see it is all
0s. It was coded this way since UFS always allocates a data
block near the end of the file, such that a hole to EOF never exists.

This patch modifies vn_generic_copy_file_range() to check for a
ENXIO returned from VOP_IOCTL(..FIOSEEKDATA..) and handle that
case as a hole to EOF. asomers@ confirms that it works for his
ZFS test case.

Test Plan

I tested it over UFS to ensure there was no regression for
a large file created via truncate(1) and asomers@ did the
same for ZFS.

Since the code was already tested for a similar case, where
the hole went as far as the "len" being copied, I believe
this should be sufficient testing.