Add a `bytes` range to the DataBreakpointInfo Request

[connor4312]

Splitting off from #445

One feature from the authors of the request include the ability to set breakpoints for a range of memory:

The "event points" map pretty well onto DAP data breakpoints, except data breakpoints can only be set for singular variables in the protocol.

To allow a range to be set, we need a corresponding capability

interface Capability {
  // ... in addition to exisitng properties:

  /**
   * The debug adapter supports padding `length` in the `DataBreakpoint` request.
   */
  supportsDataBreakpointBytes?: boolean;

Then there may be an additional field in the info request, which specifies the number of bytes following the address in which the debugger should stop:

interface DataBreakpointInfoArguments {
  // ... in addition to exisitng properties:

  /**
   * Clients may set this variable only if the `supportsDataBreakpointBytes`
   * capability is true.
   * 
   * Clients may pass this to request a reference to a range of memory rather
   * than a single variable or expression. Data breakpoints set using the
   * resulting data ID request that the debugger pauses within the range of
   * memory starting at address of the variable or expression,
   * and extending `bytes` exclusive bytes.
   * 
   * Treated as a hex value if prefixed with `0x`, or as a decimal value
   * otherwise.
   */
  bytes?: string;

[gregg-miskelly]

dataBreakpointInfo is really about asking a debug adapter to provide a description of how to set a data breakpoint on a variable. In this scenario, it doesn't seem like there is a variable involved -- it seems like the user is really inputting an address, size, and access settings.

Questions:

1. Can we come up with a standard set of properties for 'access settings'? Or do we really need a custom request (like launch arguments)?
2. Instead of extending dataBreakpointInfo, should we just extend DataBreakpoint so that when a new capability is present, dataId can have some special value (empty string?) and then there is a new field that carries additional properties about the address range?

[kkistm]

I agree with @gregg-miskelly about DataBreakpointInfo usage. Two fields from this interface, variableReference and frameId, are not useful for data breakpoints.
What about to introduce DataRangeBreakpoint or MemoryRangeBreakpoing interfaces, inspired by DataBreakpoint but tailored to the specific case? With a corresponding set*() method?

[markgoodchild]

I agree with @kkistm that making the interface more precise makes the purpose easier to understand and its usage cleaner.

[connor4312]

Thanks for the feedback. How about we introduce an alternative request, like DataAddressBreakpointInfo, with arguments

interface DataAddressBreakpointInfoArguments {
  /**
   * The address of the data for which to obtain breakpoint information.
   * Treated as a hex value if prefixed with `0x`, or as a decimal value
   * otherwise.
   */
  address: string;

  /**
   * If passed, requests breakpoint information for an exclusive byte range
   * rather than a single address. The range extends the given number of `bytes`
   * from the start `address`.
   * 
   * Treated as a hex value if prefixed with `0x`, or as a decimal value
   * otherwise.
   */
  bytes?: string
}

The response is identical to the DataBreakpointInfo response, allowing the resulting dataId to interop with the existing SetDataBreakpoints request.

This covers the 'access settings' menu with the exception of the "mask" field, though that could be added as a property.

Of course this comes with a capability.

interface Capability {
  // ... in addition to existing properties:

  /**
   * The debug adapter supports the `dataAdressBreakpointInfo` request.
   */
  supportsDataAddressInfo?: boolean;

[kkistm]

@connor4312, the proposition about DataAddressBreakpointInfo sounds good for me, keeping in mind that additional properties could be added as needed.

[ZequanWu]

https://microsoft.github.io/debug-adapter-protocol/specification#Requests_DataBreakpointInfo says "If variablesReference isn't specified, this can be an expression." in DataBreakpointInfoArguments's name field. If this request is added, does this mean the name could not be an expression anymore? If no, we still need the number of bytes to watch from expression.

[connor4312]

This was finished in #461

@ZequanWu see that PR for what we ended up doing, let us know if you have any feedback. Thanks!