Update tmpfile() existence detection

[rincebrain]

Motivation and Context

Linux changed the tmpfile() signature again in torvalds/linux@6521f89,
which in turn broke our HAVE_TMPFILE detection in configure, leading to
#12060 .

Description

Update that macro to include the new case, and change the signature of
zpl_tmpfile as appropriate based on the new detection.

How Has This Been Tested?

• Verified that O_TMPFILE failed with EOPNOTSUPP on ZFS on Debian bullseye, kernel 5.12.0 with vanilla git and passed with this PR.
• Verified that O_TMPFILE still works as expected on the aforementioned system running a 5.10.0 kernel
• Verified same on Ubuntu 18.04 box running 4.15.0-143-generic
• Verified that all the above systems pass all the tmpfile-related tests in ZTS

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[dankamongmen]

Hey there. I filed the original bug (#12060), after running into it as part of dankamongmen/notcurses#1653. Just wanted to say that I tested a rebuilt zfs-2.1.99-1, and I'm no longer drawing ENOTSUPP. The regression appears remedied. Thanks for running with it, @rincebrain!

[behlendorf]

Whoops. This looks good, it seems we missed this case when updating the rest of the VFS hooks in #11712. Thanks for sorting it out.

[rincebrain]

I suppose it would be a fair bit of work to refactor many of the kernel version checks to say "if ([target kernel version] >= [expected version for this check to start passing] && [target kernel version] < [version where the API changed again] && [this test returned false]), hard fail the configure", even if people were somehow okay with making Python a hard dependency and I stole the version comparison from #12073, to reduce the chances of something like this silently happening again.

[behlendorf]

Thankfully this kind of thing doesn't happen all that often, usually it's caught by the CI. In this particular case it slipped through because the tmpfile() ZTS tests were written in such a way that they automatically disable themselves when the kernel support for O_TMPFILE is missing (it was added in the 3.11 kernel). See tests/zfs-tests/tests/functional/tmpfile/setup.ksh, we could make that check smarter potentially for this specific case. Though linking any of these checks to a specific kernel version can be dodgy too since distributions have been known to change kernel interfaces and backport patches from upstream. This is mainly why we rely on autoconf to check the actual devel headers to determine what is and isn't available.

[rincebrain]

Sure, I understand why this particular case didn't get caught, but that's the point - my thought was "distinguishing between "feature absent and kernel too old" and "feature absent when kernel should have it"".

So if we're checking for "newer than 3.0 and the test fails", and someone backported to 2.6.20, that's fine, this hypothetical test couldn't catch it failing unexpectedly, but (almost) nothing short of the Linux kernel versioning its interfaces would let you know that "oh, it's broken because it's too new, not because it's too old" in those cases. (I guess you could try to enforce always having a test case for every variant of a feature you support, e.g. in this case adding a test after the other tmpfile checks that verifies the error that gets spit back for trying to define .tmpfile is "no such member" not "incorrect argument types" (or however the compilers would phrase it), but down that road madness and terrible parsing lies.)

Though that would involve parsing version numbers...again, but with no eventual Python packaging escape hatches unless it was made a hard dep {for this hypothetical check, for everything}, which I'm not a fan of as an idea. (Though if the checks only applied in the case that it was present, maybe that'd work...)

It was all a hypothetical anyway. I'm unlikely to go down a rabbit hole trying to build this unless I notice it breaking like this again.