x/tools/gopls: consider adding opt-in support for symlinks

[stamblerre]

We currently have partial support for symlinks and no test coverage. We believe that some of the timeouts on the openbsd builder may be caused by the latency of evaluating symlinks.

Some options:

• Remove support for symlinks completely and document this
• Add opt-in OR opt-out support for symlinks via a configuration
• Support symlinks by default, but disable support for symlinks in tests

/cc @heschik @findleyr

[gopherbot]

Change https://golang.org/cl/273190 mentions this issue: internal/lsp: disable support for symlinks pending decision

[gudvinr]

Remove support for symlinks completely and document this

This would painfully impact productivity if your editor has no support for opening multiple modules in single workspace.
I spent a lot of time recently to make it work and it still doesn't work well.

First of all, experimentalWorkspaceModule requires modules to be present inside single workspace root.
That means you must put all linked projects there.
So, let's say you have multiple projects (projectA and projectB) that use library1 and you want to use on-disk version of this library in both.
Your only option is to make a copy in both projectA and projectB. And it is bad. But that could be easily solved with symlinking library1 into both projects.

Yes, you can make gopls.mod and maintain that by hand. But that's not really a comparable option.

This also can be solved by allowing LSP client to provide workspace information (e.g. vscode has multi-root workspaces where every root not required to be in same subdirectory). But I am not aware if that's a thing right now.

[gopherbot]

Change https://go.dev/cl/454355 mentions this issue: gopls/internal/lsp: avoid I/O in URI comparison operations