[llvm] [lldb-dap] Add breakpoints after debugger initialization in DExTer (PR #169744)

[Stephen Tozer via llvm-commits]

SLTozer wrote:

For some post-commit review (sorry for getting to this late!) - the sequencing here doesn't look correct according to the [DAP specification](https://microsoft.github.io/debug-adapter-protocol/overview). According to the specification, the `launch` request should only be responded to by the adapter after the `configurationDone` request has been responded to. There isn't an exact linear order given to the setup steps, but the explicitly given orderings are:

- All configuration commands (breakpoints and `configurationDone`) from the client must only be sent after the `initialized` event has been received.
- The `launch` request must only be sent after the `initialize` response has been received.
- The `launch` response must only be sent (and the debug session started) after the `configurationDone` response has been sent.

Dexter does not honor the first rule - there was no explicit wait for the `initialized` event before flushing breakpoints - but the practical reason for this is that LLDB doesn't send the `initialized` event until after the `launch` response, meaning that that rule has to be ignored. Now however, Dexter is expecting the `launch` response before sending any configuration requests, which is also incompatible with the spec as written, which causes issues when interfacing with other DAP implementations.

Is it possible to implement the feature added in #163653 while also adhering to the DAP specification? As far as I can tell, the only necessary difference in terms of event sequencing would be to defer the response to the launch request until after the configurationDone response has been sent, or to accept configuration commands before sending the launch response, so that Dexter can still send requests in the order launch->breakpoints->configurationDone without conflicting with the debugger.

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