feat: Support creating unreachable named tempfile on Linux

[NobodyXu]

There's a better way to create tempfile that persists after writing is done on Linux using O_TMPFILE.

While it only supports ext2, ext3, ext4, UDF, Minix, tmpfs XFS (Linux 3.15), Btrfs (Linux 3.16), F2FS (Linux 3.16), ubifs (Linux 4.9), and needs either CAP_DAC_READ_SEARCH or a procfs to be mounted, it's still a pretty good solution.

It prevents any other process from manipulating the file (except through procfs) until the caller process marked it as ready, and it removed the file on process exit even if the rust destructor is not called (e.g. panic during unwinding, calling exit directly)

Originally posted by @NobodyXu in https://github.com/Stebalien/tempfile/issues/273#issuecomment-1925701199

[NobodyXu]

@Stebalien I agree with you that a generic cross-platform impl, I just want to provide a potentially better, though platform-dependent way of fixing the issue I know.

I believe it would be best to add this to SpooledTempfile, which enable us to fallback to generic impl, or add a new type for this.

I'm not aware of anyway of achieving this in freeBSD, macOS or Windows, it would be great if there 's some way of achieving it on these OSes.

[Stebalien]

We'd have to have an entirely new type. If we changed SpooledTempFile, we'd either:

1. Not be able to implement persist on some platforms.
2. Lose the current guarantees (by not immediately removing the file on, e.g., MacOS).

We'd need some new temporary "persistable" temporary file type that's named on some platforms (where we have no choice) but not on others.

I'll have to think about it, but I'm skeptical. Either:

1. You only care about Linux, in which case you should use a special-purpose crate for that.
2. You need something that's cross-platform, in which case you can't rely on this feature anyways.

[NobodyXu]

That's true...Maybe I should write a dedicated crate for this.