bootloader: replace stray MAX_PATH with PATH_MAX

[rokm]

On Windows, pyi_path_fopen() erroneously uses MAX_PATH (260) instead of PATH_MAX (4096) to convert the filename to wide characters, which causes MultiByteToWideChar() call in pyi_win32_utils_from_utf8() to fail with

MultiByteToWideChar: The data area passed to a system call is too small.

when we try to open a file with a long filename (> 260).

Due to lack of error checking, the resulting wfilename array ends up with random content, and the _wfopen() call either fails
(in read-only mode) or creates a randomly-named file (in write mode).

Fixes #5615.

[rokm]

We also really should go through the codebase and add checks for failed pyi_win32_utils_from_utf8 calls, especially in cases when the result array and its max size are given by the caller. Because if the call fails, the array will have its original content (most likely uninitialized) which will result in inconsistent behavior.

But that's a fight for another day, and another PR...

[bwoodsend]

Well that didn't take long...

[bwoodsend]

I guess actually before I get too overexcited could you build a wheel containing rebuilt bootloaders and ask @hackenjoe to verify it? Or we could add a very long path test?

[rokm]

I'll add a long filename test. I'm beginning to suspect that #5615 has an unrelated underlying issue that has uncovered this path-length related bug...

[rokm]

Alright, here's the revised version. The added test_onefile_longpath should fail on Windows before bootloader is rebuilt. I've also decoupled the commit from the issue (i.e., removed the reference from the commit message and tied the news fragment to PR number instead of issue number).

[rokm]

The added test_onefile_longpath should fail on Windows before bootloader is rebuilt.

I guess it's comforting to know that the test also fails after bootloader is rebuilt if the test system doesn't have long names enabled...

It also explains the fopen: No such file or directory message from #5615 that I haven't been able to reproduce.