On Windows, use GetTempPath2 for Filename.get_temp_dir_name

[MisterDA]

We can use the WinAPI to get the temporary directory. It's what Rust and Golang do.
A caveat is that GetTempPath2 is only available since Windows 10 21H1. As older Windows 10 versions are still supported by Microsoft, we need to fallback to GetTempPath if GetTempPath2 isn't found.
I use a one-time initialization object (available since Vista) to avoid races when initializing the function pointer to either GetTempPath2 or GetTempPath.

[nojb]

Suggested change

	Under Windows, it uses [GetTempPath2] (since Windows 10 21H1), or
	[GetTempPath], and returns:
	Under Windows:

(how it is implemented is an implementation detail)

[MisterDA]

I added it because the standard libraries of Rust and Golang documented it.

[nojb]

We don't do this anywhere else, so it would be a bit unusual to add it here.

[nojb]

Can you say a few words about this (seemingly unrelated) change?

[MisterDA]

I needed to move the Windows code to C. It wasn't clear what to return from caml_sys_temp_dir_name for Unix, and as I needed to add an external ... to filename.ml, it seemed more appropriate to move all the code to the C side, including for Unix, rather than adding a dummy symbol for Unix.

[MisterDA]

Are you convinced by this part of the change?

[nojb]

Seems fine, yes.

[dra27]

I'm slightly less convinced (just on the idea of unintended consequences) - for #12624, we decided it was OK to have "asymmetric" primitives for this kind of thing. That feels OK here, too - so just have the Unix side of the primitive return an empty string and simply not use it?

[MisterDA]

so just have the Unix side of the primitive return an empty string and simply not use it

Applied, thanks!

[nojb]

LGTM

A second approval is necessary I think. @dra27: could you take a look? Thanks!

[dra27]

Definitely for this change, thanks, but it would be good to be motivating it from the security standpoint (what other languages are doing is reassuring, but it's not a reason in and of itself). I'm puzzled by the way InitOnceExecuteOnce is being used - I thought the point of it was to eliminate static variables where the initialisation state was unclear, but I may well be missing a subtlety (cf. the example on MSDN where the point is that there is no static HANDLE value)

[dra27]

I'm slightly less convinced (just on the idea of unintended consequences) - for #12624, we decided it was OK to have "asymmetric" primitives for this kind of thing. That feels OK here, too - so just have the Unix side of the primitive return an empty string and simply not use it?

[MisterDA]

Thanks for the reviews @dra27, @nojb! The code is more simple now. You seem to have divergent opinions on the documentation. I'm more inclined to just mention GetTempPath2 and GetTempPath rather than restating their behavior.

Note that there is also a call to GetTempPath in my socketpair emulation for Windows. I have a couple of bug-fixes for that code that I'll submit shortly, I'll join the switch to GetTempPath2 alongside.

[MisterDA]

I think the CI failure is transient, I cannot reproduce it locally.

[dra27]

Thanks, @MisterDA!