[wasm][debugger] Move the breakpoint line after applying changes

[thaystg]

When hot-reloading code with new lines added, VS automatically updates the breakpoints by sending Remove/SetBreakpoint commands.

Add a test case for the reload, with simulated VS part.

[ghost]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Add test case to prove that changing a line and moving the breakpoint to the next line as it's done by VS will work.

Author:	thaystg
Assignees:	thaystg
Labels:	area-Debugger-mono
Milestone:	-

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Add test case to prove that changing a line and moving the breakpoint to the next line as it's done by VS will work.

Author:	thaystg
Assignees:	thaystg
Labels:	arch-wasm, area-Debugger-mono
Milestone:	-

[radical]

LGTM! 👍

[lewing]

This looks fine but I think we should review how we're handling the queued breakpoints and how they get applied. We should also walk through what events are generated when a delta is applied there are some potential complexities with the ordering there.

[thaystg]

We could decide to: have a list of all breakpoints that are not bind because the line is not valid, and try to bind them again after receiving an apply changes. I'm not sure if this makes sense. I will do more tests in a console app running on coreclr. Because each time that we apply the updates we would need to loop in this list of invalid breakpoints and try to set them again.

The events generated when delta is applied are okay I think:

• debugger-agent receives the update and after it's applied it sends a message to debugger-libs/browserDebugProxy to apply the changes on the debugger side, like updating offsets and adding new variables, and then we look at all the breakpoints for that method and get the new offset and set them again.