dap: support buildDir attribute in the Launch request

[hyangah]

Like dlv debug or dlv test commands, dlv dap builds the target program/test
from the current directory where the dlv command is invoked.
There is cwd attribute in the launch argument, but that corresponds to --wd flag
and determines only the working directory of the target program.

We assumed the client can run dlv dap from the correct directory required for build
until now. However, we recently heard of some cases where launching dlv dap from
the right directory is not easy.

• vimspector always launches the debug adapter process from the workspace root.
  Currently building targets outside of the workspace, or outside of the main module isn't
  possible.
• some clients may want to lazily determine the launch target after starting dlv dap
  process.
• if we ever make a dlv dap process to serve multiple launch requests (sequentially or not)
  building the build directory and the dlv's process working directory isn't a good idea.

So, allow a new, optional attribute that specifies the build directory
(where go build command runs).

cc @polinasok @suzmue

[polinasok]

Please help me understand the uses cases better:

• vimspector always launches the debug adapter process from the workspace root.
  Currently building targets outside of the workspace, or outside of the main module isn't
  possible.

Do you have a reference to the discussion with vimspector? I am curious to understand why they always start the process from the workspace root only as opposed to what vscode-go does.

• some clients may want to lazily determine the launch target after starting dlv dap
  process.

Do you have a specific client/use case in mind?

• if we ever make a dlv dap process to serve multiple launch requests (sequentially or not)

Is this so we can have a long-running debug adapter server that the same client can start once and direct all debug sessions to like in #2329)

building the build directory and the dlv's process working directory isn't a good idea.

"build the build directory and" - do you mean combining (because dlv's working directory, i.e. where dlv is launched, will be determined by the first launched request while the next launch request might use a target from a different location?

[hyangah]

Note: we ended up implementing delveCwd instead of buildDir. The attribute changes Delve's working directory using os.Chdir.

I realized I didn't answer to Polina's question here

Do you have a reference to the discussion with vimspector? I am curious to understand why they always start the process from the workspace root only as opposed to what vscode-go does.

vimspector is a general dap client for all languages, not specialized for any particular language.
This build directory restriction is very Go specific (note: before Go modules, vscode go itself didn't have such restriction), and many debug adapters don't handle build steps.

• some clients may want to lazily determine the launch target after starting dlv dap
  process.
  Do you have a specific client/use case in mind?

Anyone who starts dlv dap externally and needs to work with nested modules. The latest case was the google cloud code users who launches dlv process inside a prebuilt container.

if we ever make a dlv dap process to serve multiple launch requests (sequentially or not)
Is this so we can have a long-running debug adapter server that the same client can start once and direct all debug sessions to like in #2329)

Originally yes, but it seems like we are abandoning this plan for now.

building the build directory and the dlv's process working directory isn't a good idea.
"build the build directory and" - do you mean combining (because dlv's working directory, i.e. where dlv is launched, will be determined by the first launched request while the next launch request might use a target from a different location?

My intention was to keep the dlv's working directory as it is started (not determined by the first or any request). But this plan was dropped.