debug: be explicit about supporting conditional breakpoints

[polinasok]

According to the dap spec:

/**
   * An optional expression for conditional breakpoints.
   * It is only honored by a debug adapter if the capability 'supportsConditionalBreakpoints' is true.
   */
  condition?: string;

Our debug adapter does not set this capability on initialization, but it does appear to support conditional breakpoints (via "Edit Breakpoint"). We should set the capability and add tests for this to solidify the support. This way when the breakpoint is set, it won't have the "!" and an error message on hover, which are misleading because it will actually work.

We would also need to set this correctly in debugAdapter2 as well as it reports capabilities before dlv is launched. This feature has recently been added to dlv-dap (now tracked under #844)

[suzmue]

I'll add the tests update the configuration for the old debug adapter.

[gopherbot]

Change https://golang.org/cl/262346 mentions this issue: src/debugAdapter: indicate that conditional breakpoints are supported

[gopherbot]

Change https://golang.org/cl/264198 mentions this issue: src/debugAdapter2: indicate that conditional breakpoints are supported

[hyangah]

Related

#822: initializeRequest is still handled by the thin adapter; it's desirable to forward this to delve dap

#794: the stable version of delve may not have the capability so this can be a lie if we set it now. OTOH, we are currently operating with an implicit assumption - users should use the latest master version of delve to use. So, I think setting this true isn't too bad. cc @polinasok

[hyangah]

I will remove this from v0.18.0 milestone, and let it be tracked as a DelveDAP bug.

[polinasok]

I mentioned setting this in debugAdapter2 in my opening description, but technically that's a separate issue and can be generalized to all new capabilities. As @hyangah reflected above, there are multiple options here for addressing this, so let's move the tracking/discussion for the long-term solution to another issue #844 that could be an umbrella for comparing and contrasting these options.

[hyangah]

Thanks for the followup @suzmue and @polinasok . I will close this and place it back to v0.18.0 milestone for archive purpose.
Thanks @suzmue for the fixes.