[hxb] Ignore invalidations during display requests

[kLabz]

• Built on top of [hxb] Signature dependencies - part 2 #11659 for now
• Make sure display requests don't alter cached data (binary_cache in compilationCache.ml)
• Restore all (except current display file) hxb modules as MSGood during display requests
• This does not break workflow of working on several files without compiling, but changes will only be available in other files if you save your changes (file time changes still invalidates the module)
• Nightlies can be downloaded there https://github.com/HaxeFoundation/haxe/actions/runs/9014655440?pr=11660

I tested this branch with all projects I had available, without detecting any issue (at least not any new issue) and got very promising results (see below).

Notes:

• my computer is a bit slow, so mostly look at timing differences and not raw numbers
• some framework/user code still need some tweaks to reduce invalidation / macro work
• most if not all heaps games tested needed a small patch to hxbit letting it run its macros during display requests (but that's also true for other nightlies)

[Shiro project]

• 4.3.4: not compiling
• 5.0.0-alpha.1+c325889:
  • hover without invalidation 1~2s
  • completion 4~6s
  • hover with invalidation 4~5s
• this branch:
  • all requests under 1s

[Shiro project]

• 4.3.4
  • hover request without invalidation 0.1s
  • completion 5s
  • hover request with invalidation 4s
• 5.0.0-alpha.1+c325889:
  • hover request without invalidation 1~1.2s
  • completion 4~6s
  • hover request with invalidation 4~5s
• this branch:
  • all requests under 1s

[Shiro project]

• 4.3.4: not compiling
• 5.0.0-alpha.1+c325889:
  • hover request on Game.hx without invalidation 400~700ms
  • completion on Game.hx broken
  • hover request on Game.hx with invalidation broken
• this branch:
  • hover request on Game.hx without invalidation 160~300ms
  • completion on Game.hx 200~300ms
  • hover request on Game.hx with invalidation 160~300ms

[Personal heaps game] (very similar results on other small[ish] scale projects)

• 4.3.4
  • hover request without invalidation 30~50ms
  • completion 120~140ms
  • hover request with invalidation 120~160ms
• 5.0.0-alpha.1+c325889:
  • hover request without invalidation 170~280ms
  • completion 270~380ms
  • hover request with invalidation 250~350ms
• this branch:
  • hover request without invalidation 80~90ms
  • completion 90~140ms
  • hover request with invalidation 90~140ms

Other "small scale" projects

Smaller projects that tend to have no issues with Haxe 4 and are running diagnostics still have much faster display requests when cache has just been filled (after compilation or diagnostics), though even those can have slightly better timings (with diagnostics disabled at least) when files start to be invalidated.

Misc

• [Shiro project] - 4.3.4: 20+ seconds; 5.0.0-alpha.1+c325889 and this branch ~15sec including 12+ seconds of macros and rest in typing; something is wrong on user code there
• [Shiro project] currently not getting completion with nightlies for unrelated issues (and not compiling with 4.3.4)

[kLabz]

Nice, this check works :)

Edit: and after setting development as base branch:

👌

[Simn]

This is neat, it's nice that we can do something like that now. Having a two-layer cache like this makes sense to me because we separate the properly cached data from the working data, which should also give a good memory layout for the GC.

I'll have to review the server.ml changes more in-depth because at the very least they duplicate some code.

Also I find reset to be a misleading name for something that merely clears the temp cache.

[kLabz]

Yeah, that's something I wanted to do pretty much since the beginning but wasn't working well on previous attempts, needed that separate "working data".

Right, I cleaned up a bit, hope it's better like that!