[llvm] [Dexter] Adjust launch sequencing to align closer with DAP spec (PR #170523)

[John Harrison via llvm-commits]

================
@@ -763,23 +763,39 @@ def launch(self, cmdline):
 
         launch_request = self._get_launch_params(cmdline)
 
-        # Per DAP protocol, the correct sequence is:
+        # Per DAP protocol, we follow the sequence:
         # 1. Send launch request
-        # 2. Wait for launch response and "initialized" event
-        # 3. Set breakpoints
-        # 4. Send configurationDone to start the process
+        # 2. Set breakpoints
+        # 3. Send configurationDone to start the process
+        # 4. Wait for launch and configurationDone responses, and a "process" event, to confirm successful launch
+        # NB: Technically, we should also wait for the "initialized" event before sending the launch request, but in
+        # practice there are DAP implementations that do not send the initialized event until post-launch, and all
+        # adapters seem to accept us not waiting for the initialized event, so ignoring it gives maximum compatibility.
----------------
ashgti wrote:

In VSCode at least, the debug session start sequence is as follows:

These two happen in order:
* client sends `initialize` request
* client sends `launch` or `attach` request

Often these two will have be seq=1, seq=2 respectively, see https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/browser/debugService.ts#L708-L709

Independently, the client performs the following:
* wait for the adapters to send `initialized` event (after the `initialize` request has returned is when the event handler is installed)
* client sends zero or more `setBreakpoints` requests
* client sends one `setFunctionBreakpoints` request (if corresponding capability `supportsFunctionBreakpoints` is true)
* client sends a `setExceptionBreakpoints` request if one or more `exceptionBreakpointFilters` have been defined (or if `supportsConfigurationDoneRequest` is not true)
* client sends one `configurationDone` request to indicate the end of the configuration.

So, strictly speaking, there is no requirements from the spec on when `initialized` is sent beyond that it happens sometime after the `initialize` response.

In lldb-dap we don't send the `initialized` event until after we receive the `launch` or `attach` request, see https://github.com/llvm/llvm-project/blob/main/lldb/tools/lldb-dap/Handler/LaunchRequestHandler.cpp#L75 and https://github.com/llvm/llvm-project/blob/main/lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp#L174.

Delve (for go) also doesn't send `initialized` until the end of the `launch` or `attach` request see https://github.com/go-delve/delve/blob/62d821a5e490ceb93712a3eed7aaadf37482d39e/service/dap/server.go#L1301 and https://github.com/go-delve/delve/blob/62d821a5e490ceb93712a3eed7aaadf37482d39e/service/dap/server.go#L2213

https://github.com/llvm/llvm-project/pull/170523