<filesystem>: Fix the path returned when there is an error with temp_directory_path and simplify the validation logic

[YexuanXiao]

Fix #5557.

In the current implementation, temp_directory_path would first use GetTempPath/GetTempPath2W to obtain the temp path, then use GetFileAttributesW to obtain file attributes to verify if it was a directory. If the file is not a directory but is a symlink, the symlink would be opened to verify that the symlink is correct. Since GetFileAttributesW internally opens the file and uses GetFileInformationByHandleEx to obtain file attributes, the current logic contains redundancy. Instead, we should unconditionally open the path obtained by GetTempPath/GetTempPath2W, follow symlinks, and verify that it is a directory through GetFileInformationByHandleEx.

[YexuanXiao]

STL/stl/inc/filesystem

Lines 4049 to 4052 in 7841cf8

	if (_Temp_result._Error == __std_win_error::_Max) { // path could be retrieved, but was not a directory
	_Ec = _STD make_error_code(errc::not_a_directory);
	} else {
	_Ec = _Make_ec(_Temp_result._Error);

@StephanTLavavej What's the significance of using different categories here? The standard doesn't seem to require it.

[fs.err.report]/3.1

If a call by the implementation to an operating system or other underlying API results in an error that prevents the function from meeting its specifications, the error_code& argument is set as appropriate for the specific operating system dependent error.

[StephanTLavavej]

What Windows error code would we synthesize to indicate "not a directory"?

[YexuanXiao]

What Windows error code would we synthesize to indicate "not a directory"?

If the path points to a symlink but the target does not exist then CreateFile will report _File_not_found; or the target's class does not match the symlink, then CreateFile will report _Directory_name_is_invalid. For consistency, L830 might need to be the same.

The File APIs does not seem to strictly distinguish between files and directories in its error codes, and the error codes appear to be unstable. Unless necessary, identifying or conversion should be avoided.

[StephanTLavavej]

There are a lot of logic changes here, much more than are needed to simply clear the path on error. Can you please update your PR description to explain how the code is changing? This is both for my benefit while reviewing, and for future maintainers/contributors to understand what changed.

Edit: Indeed, it looks like these are unrelated behavioral changes. We try to avoid mixing together bugfixes with other behavioral changes (or even cleanups) unless they are inextricably linked.

[YexuanXiao]

There are a lot of logic changes here, much more than are needed to simply clear the path on error. Can you please update your PR description to explain how the code is changing? This is both for my benefit while reviewing, and for future maintainers/contributors to understand what changed.

Edit: Indeed, it looks like these are unrelated behavioral changes. We try to avoid mixing together bugfixes with other behavioral changes (or even cleanups) unless they are inextricably linked.

Should I split it into two PRs?

[StephanTLavavej]

Should I split it into two PRs?

Yes, please.