Add Udon breakpoint UI - breakpoint-related operations

[Yicong-Huang]

This PR adds the Udon UI for breakpoint-related operations, including setting a breakpoint, removing a breakpoint, adding a condition to a breakpoint, and hitting a breakpoint.

Adding/Removing breakpoints with optional conditions.

Manually continue the execution and breakpoint hit:

Limitations:

• It will pause the UDF upon any breakpoint-related operations. It will not automatically continue/resume the execution.
• Currently, the breakpoints are only to be set during a running Python UDF operator. Submitting a new execution will remove all debugging states, including previously set breakpoints.
• Some states are stored in frontend (in UDFDebugService) only. They need to be retrieved back from backend debugger.

[aglinxinyuan]

A few questions regarding the UI design:

1. Is it intentional that I can only set breakpoints while the workflow is running?
2. If breakpoints can only be set when the workflow is running, could we hide the option when unavailable? Currently, when I attempt to set a breakpoint, it prints break: line number, but the breakpoint isn’t actually set, which is a bit confusing.
3. Can we position the breakpoint icon closer to or directly on the line number? The padding between them is too large, making it difficult to find the correct spot to click.
4. Should users be able to set breakpoints in multiple UDFs simultaneously? If not, we should disable the breakpoint option in the second editor.
5. If multiple editors can support breakpoints, the console isn’t switching to the active editor after a breakpoint is set. For example, after setting a breakpoint in Editor 2, the console still shows the content of Editor 1. Ideally, the console should automatically switch to the current editor after it's highlighted, but the breakpoint is preventing this switch.

[Yicong-Huang]

A few questions regarding the UI design:

1. Is it intentional that I can only set breakpoints while the workflow is running?

Yes. For this PR, we will have this assumption as debug states are stored in the backend (although some partial states are cached in the frontend as described in the PR description, the backend still has the ground truth). Later we will relax this assumption by introducing some frontend debug state life cycle.

2. If breakpoints can only be set when the workflow is running, could we hide the option when unavailable? Currently, when I attempt to set a breakpoint, it prints break: line number, but the breakpoint isn’t actually set, which is a bit confusing.

Good suggestion, I have changed it to only enable breakpoint operations while a UDF is either running or paused to avoid confusion. Note that a special case is when the workflow is terminated, we do not change the frontend state (it will keep the old state). Thus killing a workflow will not disable breakpoint operations. In future PRs, I will introduce breakpoint operation logic during other states, which will resolve the issue.

3. Can we position the breakpoint icon closer to or directly on the line number? The padding between them is too large, making it difficult to find the correct spot to click.

This is controlled by the library. We could potentially alter the CSS by ourselves, but I prefer to keep it as it is and only change it if needed.

4. Should users be able to set breakpoints in multiple UDFs simultaneously? If not, we should disable the breakpoint option in the second editor.

I think you mean "do we allow a single user to set breakpoints on two UDFs". Currently, I assume there is only one UDF at a time to set a breakpoint with. To relax the assumption, it is related to the operator highlighting logic. In future PRs, I can relax the assumption.

5. If multiple editors can support breakpoints, the console isn’t switching to the active editor after a breakpoint is set. For example, after setting a breakpoint in Editor 2, the console still shows the content of Editor 1. Ideally, the console should automatically switch to the current editor after it's highlighted, but the breakpoint is preventing this switch.

Thanks. Yes it is related to highlighting logic. Will handle it in future PRs.

[aglinxinyuan]

LGTM!