Fix concurrency issue in Eval plugin

[pepeiborra]

The test suite often fails with interactive eval errors like the one below:

GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
  interactive_Ghci1_evalPrint_closure

During the Evaluate command, we first install a special "evalPrint" closure and then kick off the evaluation. These two steps are not atomic, and I think the error above arises when the mutable HscEnv_dynLinker is mutated by another concurrent build or evaluation in between these two steps.

In this PR we duplicate the dynamic linker context in order to isolate it from concurrent changes.

[jneira]

Setting -j2 for the hls executable (as #2296 does for fix the func-test suite for windows and ghc-9) maybe would make this less likely to be triggered 😟

[wz1000]

I don't think this will work. IIRC the linker state in the MVar is a reflection of the actual state of the dynamic linker. Simply copying the MVar in haskell-land will not actually duplicate the state of the runtime linker. Maybe @hsyl20 can comment?

[pepeiborra]

I don't think this will work. IIRC the linker state in the MVar is a reflection of the actual state of the dynamic linker. Simply copying the MVar in haskell-land will not actually duplicate the state of the runtime linker. Maybe @hsyl20 can comment?

Thanks for pointing this out @wz1000 ! That makes sense, I suppose an alternative solution would be to invent unique names for the evalPrint closure

[hsyl20]

@wz1000 is right, the loader state is still shared in the RTS (cf https://gitlab.haskell.org/ghc/ghc/-/issues/3372). https://gitlab.haskell.org/ghc/ghc/-/commit/0dc7985663efa1739aafb480759e2e2e7fca2a36 replaced the global var holding the loader state with an MVar but the C side hasn't been updated to support several loader environments.