Refactor hls-test-util and reduce getCurrentDirectory after initilization

[soulomoon]

What's done

• Refactor the runSession* family function, properly add TestConfig, runSessionWithTestConfig, as the most generic runSession* function.
• remove raraly used variants of runSession* functions and replaced by runSessionWithTestConfig.
• migrate ExceptionTests ClientSettingsTests CodeLensTests CPPTests CradleTests to use the hls-test-utils
• Only shift to lsp root when current root is different from the lsp root in DefaultMain of ghcide.
• Remove most usage for getCurrentDirectory(After DefaultMain is called), Only remain those in top level of wrapper and exe, implement Overhauling the HLS testsuite #3736 (comment)

What's remains:

• golden tests are not using TestConfig, maybe we can refactor them to use TestConfig and cut the number of variants too.
• Hlint, Stan and some Template haskell tests still depend on current working dir. But they are out of our reach.
• hie.yaml specify relative files

  cradle:
  direct:
    arguments: ["-unit" ,"@a-1.0.0-inplace"
               ,"-unit" ,"@b-1.0.0-inplace" 
               ,"-unit" ,"@c-1.0.0-inplace"
               ]
  
  

[soulomoon]

The doc said hieModuleHieFile would return a full path, I guess it is not necessary to absolute it.

[michaelpj]

I'm unsure about this sort of thing. If we need it to be absolute then I think it can be sensible to absolutize it just to be sure... since we don't track it in the types or anything.

[fendor]

Perhaps we should also introduce an abstraction that tracks whether we expect a path to be absolute or relative?

[soulomoon]

Seems like a good idea, some places we might need this.
path from [ghc, hiedb, lsp client, cradle].

The ones from ghc should depend on how we load the file into ghc in sessionloader?

[soulomoon]

It is quite a mess in our codebase, we might need to open an issue and try to sweep and standardize them.

[soulomoon]

Stan is blocking

https://github.com/soulomoon/haskell-language-server/blob/2ebfafcea751adb8d0be9c1ad9c40a4f8771f261/plugins/hls-stan-plugin/src/Ide/Plugin/Stan.hs#L144

         -- Note that Stan works in terms of relative paths, but the HIE come in as absolute. Without
         -- making its path relative, the file name(s) won't line up with the associated Map keys.

----------------update

Same for hlint, will shift to root only for these test

[soulomoon]

Again, thank your for the reviews and suggestions, expecially since this PR contains a lot of changes, you have done me a great favor of tracking everything down ! I could not do it without your help.

[fendor]

Just some more attention to the Note, I still don't quite get the LSP root thingy, where does this affect us?

[fendor]

Sorry, I don't quite get this, which root dir is this now?

[soulomoon]

Just some more attention to the Note, I still don't quite get the LSP root thingy, where does this affect us?

LSP root is deprecated, @michaelpj send me the link,
I guess that means we should cleanup dependency on the project root(Or $CWD) thing gradually, so muti workspaces can actually be supported when we use absolute path everywhere.

That might not be possible unless we have everything adapted to it, things like hlint and evaluation of template haskell.
But we should still be working towards the goal.

I'll add this to the note too.

[michaelpj]

I think we might want to seriously consider using one of the typed path libraries so we can assert that we have absolute paths everywhere. I agree it's just extremely unclear how you are supposed to deal with relative paths of any kind. There's also the issue that some of the tools we call like cabal are working directory sensitive, I don't know if we currently call cabal with --project-file or whatever we need to get it to run "as if" it were in a specific directory...

[fendor]

Since we spawn a new process for cabal, we use https://hackage.haskell.org/package/process-1.6.20.0/docs/System-Process.html#t:CreateProcess to set the working directory for cabal, so that is unaffected.