Attempt to repair PartialReparseTest

[mbien]

PartialReparseTest has a fairly high failure rate (a recent merge required 7 restarts).

Investigation showed that it had multiple issues. Fixing those does seem
to improve stability, however, likely does not fix the underlying race condition.
With the changes applied, 1 out of of 50 local runs failed.

But what is more important: the test is hopefully working correctly now

issues fixed:

code.replaceFirst("^", "") was used by accident. This method expects
regexps and won't have the desired effect. This essentially means
that the first parsing run had always errors since the test code
contained ^ characters.

The second parsing run, which did replace the injected snippet had
and off-by-one copy/paste mistake in one of the doRun methods.

But since the first run was already wrong, the result of reparse run
didn't really matter since both were compared - that is also why the
missing semicolon wasn't noticed in testAnonymousFullReparse2() or
the double escaped newline character in testAnonymous().

More asserts added to exclude potential document update issues.

Enabled a previously disabled test case.

first commit has the fixes, second switches to multi-line-string blocks

[mbien]

first CI run failed again (4th attempt did work)

new discoveries:

• the fixes did either make it worse or they didn't influence it while run in CI (locally it seemed to work fine)
• so I tried something else: I switched from memory FS to plain old folders, then ran it 100 times in my clone -> all green

MemoryFileSystem hasn't been changed in a while and might need some cleanup but on first glance I don't see anything suspicious. However it could be as mundane as modification timestamp precision issues when run in-memory or something similar.

Might be worth taking a closer look at it.

[lahodaj]

Looks reasonable to me. Thanks for stabilizing the test. For the record, I've ran the test locally 200 times this morning, and it never failed for me.

[mbien]

I've ran the test locally 200 times this morning, and it never failed for me.

@lahodaj did you run the original version or with this PR applied? Since to me it did also fail significantly less often locally than on CI. But since switching away from memory FS, there were no failures anymore, not locally and not on CI (100 runs).

[lahodaj]

I've ran the test locally 200 times this morning, and it never failed for me.

@lahodaj did you run the original version or with this PR applied? Since to me it did also fail significantly less often locally than on CI. But since switching away from memory FS, there were no failures anymore, not locally and not on CI (100 runs).

I was running the original version.

[mbien]

MemoryFileSystem hasn't been changed in a while and might need some cleanup but on first glance I don't see anything suspicious. However it could be as mundane as modification timestamp precision issues when run in-memory or something similar.

Might be worth taking a closer look at it.

we can likely exclude memory fs specific modification time resolution issues since I changed the impl to:

• use Instant instead of Date since it uses an internal high res offset for higher precision
• checked that all timestamps always go forward in time to exclude multi-cpu locality issues (which are rare these days but I wanted to be sure)
• updated the modification time inside the write method of the memory file, in case something doesn't close streams

this didn't help. So it is probably safe to exclude the memory fs impl itself being the problem - whats left is the MemoryFileSystem identity or timing issues outside of mem fs code. A clue that this might be about identity is the log which is different when mem fs is in use (no matter if green or red) - so the code path certainly is different somewhere.

[mbien]

updated the commit message of the last commit. I did also move the test files into their test package as @neilcsmith-net suggested on slack (unfortunately this did also not fix stability while using mem fs).

Thanks for review, planning to merge once green.