ParallelStartupTest is flaky in Windows

[yevgenp]

No description provided.

[yevgenp]

After some debugging it's become obvious that on Windows ChronicleMapBuilder#commitChronicleMapReady is not atomic. Thus concurrent read of ChronicleMap header may result in reading a wrong header size. See debug logs below:

Writing header size=1583
[Thread-2] WARN net.openhft.chronicle.hash.impl.util.CanonicalRandomAccessFiles - File locking is disabled or not supported on this platform (Windows 10). Make sure you are not running ChronicleMapBuilder::*recover* methods when other processes or threads have the mapped file open!
Read WRONG header size 879062561:thread=Thread-10,time=1718354714840
Exception in thread "Thread-10" java.lang.RuntimeException: java.io.IOException: file=D:\Java\projects\Chronicle-Map\target\issue342-gx3t99y2z1.tmp The file is shorter than the header size: 879062561, file size: 65536
	at net.openhft.chronicle.map.issue.ParallelStartupTest.lambda$test$0(ParallelStartupTest.java:35)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: file=D:\Java\projects\Chronicle-Map\target\issue342-gx3t99y2z1.tmp The file is shorter than the header size: 879062561, file size: 65536
	at net.openhft.chronicle.hash.impl.VanillaChronicleHash.throwRecoveryOrReturnIOException(VanillaChronicleHash.java:238)
	at net.openhft.chronicle.map.ChronicleMapBuilder.readSelfBootstrappingHeader(ChronicleMapBuilder.java:436)
	at net.openhft.chronicle.map.ChronicleMapBuilder.openWithExistingFile(ChronicleMapBuilder.java:1848)
	at net.openhft.chronicle.map.ChronicleMapBuilder.createWithFile(ChronicleMapBuilder.java:1725)
	at net.openhft.chronicle.map.ChronicleMapBuilder.createPersistedTo(ChronicleMapBuilder.java:1586)
	at net.openhft.chronicle.map.issue.ParallelStartupTest.lambda$test$0(ParallelStartupTest.java:31)
	... 1 more
Wrote header:thread=Thread-2,time=1718354714957

java.lang.AssertionError: expected:<16> but was:<15>

Header is determined as fully written (by FileIOUtils#readFully) before it's actually done.
I guess it's up to @peter-lawrey to decide for Windows if we can afford/fallback to an explicit locking in header writing code or document it as design/platform specifics.