fix super flaky tfdleak test on windows refs #14090

[timotheecour]

tfdleak is probably the most flaky test we have; this PR fixes that by establishing that isValidHandle is incorrect and ignoring when is returns true

I did some research (not being a windows user...), it's a a tricky topic but from what I gathered:

• isValidHandle is incorrect on windows and has false positives
• see also the test I added tests/stdlib/mfdleakIssue14090.nim which on windows will always fail (and always succeed on linux+osx)
• trying to actually use the file handles (instead of relying on what isValidHandle says) indeed would give errors, indicating it hasn't really leaked but the handle could merely be reused in the child, with a different underlying resource
• added links to relevant docs in the PR that talks about this

my "fix" is to disable the test in the case where a leak is not expected and windows sees a leak, since isValidHandle has false positives

future work

• fix isValidHandle for windows, possibly using getHandleInformation (next step towards closing tests/stdlib/tfdleak is flaky on windows + netbsd #14090)
• ensure that when isValidHandle is true, the handle is indeed usable (eg you can read from it)

incorrect types should be fixed

• I've also encountered a number of types that are incorrect (and could lead to other subtle bugs on windows), eg:

• proc getOsfhandle(fd: cint): FileHandle => should be proc getOsfhandle(fd: cint): Handle
  (FileHandle is cint whereas Handle is int or castable as int); see https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/get-osfhandle?view=vs-2019

# in lib/system/io.nim => bug
proc getOsfhandle(fd: cint): FileHandle {.importc: "_get_osfhandle", header: "<io.h>".}
# in lib/windows/winlean.nim => ok
proc get_osfhandle*(fd:FileHandle): Handle {.importc: "_get_osfhandle", header:"<io.h>".}

• proc setHandleInformation(handle: FileHandle, mask, flags: culong): cint {.importc: "SetHandleInformation", header: "<handleapi.h>".}
  is also incorrect according to https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-sethandleinformation
  => 1st param should be Handle not FileHandle

• winlean should really use distinct types eg BOOL, DWORD etc, which would make it much safer to use those bug prone window APIS

[alaviss]

this PR fixes that by establishing that isValidHandle is incorrect and ignoring when is returns true

I'm sorry, but this is not a fix.

trying to actually use the file handles (instead of relying on what isValidHandle says) indeed would give errors, indicating it hasn't really leaked but the handle could merely be reused in the child, with a different underlying resource

I'd be curious as to what is being used under that handle, maybe it's the various DLLs that's loaded by the program (due to winlean for example). The best way to check for this would be to purposefully leak a duplicated handle, then use CompareObjectHandles to verify whether the handle we are testing is the same as the handle held by the parent. I think I can try to implement this.

[timotheecour]

I'm sorry, but this is not a fix.

it's a fix for the flakiness but doesn't close #14090; the point was the test was flawed and needs a better test on windows; until then it doesn't make sense to have CI keep breaking; but if you have a better fix, I'm all for it

[treeform]

@timotheecour please help me I am getting this error, which you mentioned.

error C2664: 'BOOL SetHandleInformation(HANDLE,DWORD,DWORD)': cannot convert argument 1 from 'NI' to 'HANDLE'

Is there a way to fix that in nim? Is there a way to downgrade VC++ to a version that works? What would you recommend?

[treeform]

A solution was found here: #14980

Thanks!