Fix flaky FSW test

[danmoseley]

Fix #103753

Test does not fail for me locally; making assumption that firing even more events will this will help avoid it failing elsewhere.

1. Fix the calculation of the size of FILE_NOTIFY_INFORMATION, although this is likely not material.
2. Fire 250x the number of events that will fill the buffer, instead of 100x. Takes the 3 tests from 3 seconds total to 28 seconds for me. Guessing this is hitting some kind of IO parallelism threshold.
3. Speed up some by moving file system operations to threadpool. Takes tests to 20 seconds.
4. Halve size of buffer, also reduce to 200x. Tests are 9 seconds.
5. It's still slow so move to outerloop.

[danmoseley]

BTW error case of too small InternalBufferSize is not being tested on non Windows (which may have different error behavior/limits)

[danmoseley]

Comment says "where filePath is the path to changed file relative to the path passed into ReadDirectoryChanges." .. but the math does not use the relative path. Small beans; will cause over estimate, increasing events.

[adamsitnik]

LGTM, thank you for providing the fix @danmoseley !

[danmoseley]

Can we run outer loop on this PR? It's just speculation that this will fix the test

[jozkee]

/azp list

[jozkee]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jozkee]

#103753 also mentions FileSystemWatcher_Directory_NotifyFilter_Attributes so it won't completely fix it.

[danmoseley]

Right, not really evidence that's related. Eg., it didn't start on the same day, it only happened once.

[danmoseley]

OK, Build Analysis is recognizing all failures, so this is good to merge if you're OK with that @jozkee

[jozkee]

/backport to release/8.0-staging

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/15537894547