GLSP-1254 Fix client-server action forwarding

[tortmayr]

What it does

• Deprecate the concept of marking actions as locally dispatched by appending the __localDispatch property. This concept is a remainder of the 1.x API implementation and no longer necessary in 2.x. In addition, it conflicted with the default behavior of marking actions received from the server.

• Remove ExtensionAction bindings of RequestClipboardDataAction and SetClipboardDataAction in vscodeCopyPasteModule. These bindings where added on accident. As a consequence, related actions dispatched in the webview client where also forwarded back to the host extension where they were not handled.

Fixes eclipse-glsp/glsp#1254

How to test

Test with different integration kinds. Diagram rendering should now work again.

Follow-ups

eclipse-glsp/glsp#1259

Changelog

• This PR should be mentioned in the changelog
• This PR introduces a breaking change (if yes, provide more details below for the changelog and the migration guide)
• [API] The VsCodeGLSPModelSource and ExtensionAction are now deprecated.
  - VsCodeGLSPModelSource: Rebinding to a custom model source is no longer necessary. Use the default GLSPModelSource instead.
  - ExtensionAction: The concept of marking actions as locally dispatched ExtensionActions is no longer necessary and usage is discouraged.

[martin-fleck-at]

Thank you very much for the update, Tobias! Indeed this PR fixes the rendering of the model so we definitely want to get that in. I just noticed another issue of which I'm not sure if it is related: I can no longer save a model. It seems that the SaveAction is already marked as coming from the server, so some thing may have gotten lost here, could you please have another looks? If you think it is more work, I can also approve this and we can log a separate issue.

[tortmayr]

Good catch.
The problem here is that all actions dispatched from the host extension are actually sent to the client.
However, certain actions like (Save, Undo,Redo and RequestModel) should actually be sent to the server.
Previously this worked due to the faulty (non) marking of server-received actions. So for instance the client received a SaveModelAction and also dispatched it to the server.
Howedver, this is an unnecessary roundtrip. I introduced a sendActionToServer´ method in the GLSVscodeConnector` to directly send the actions in questions to the server without the roundtrip to the client.

Note that this is just a quick fix. We should create a follow-up to improve this behavior and use the information provided by client and server (i.e. handled action kinds to automatically derive the intended target when dispatching an action in the host extension. I have created a follow-up Ticket for that (eclipse-glsp/glsp#1259)

[martin-fleck-at]

Thank you for the quick update Tobias! I re-tested the change and now everything works much better for the workflow example.

I approve this PR for now but is the risk of adopters not breaking still rather high since we only handle known server actions for now but if there is any customization that will not work with the PR. I saw that you created a follow-up ticket (eclipse-glsp/glsp#1259) to address the client/server action gap. So if there is a high risk of breakage, that issue should be definitely treated as high priority and fixed before making any further releases, I believe.

[tortmayr]

@martin-fleck-at I have applied the changes for the follow-up PR directly in this PR. Hopefully, we can avoid any breakage with this.

I also have introduced a migration label that allows us to mark PRs that need to be mentioned/covered in the migration guide.

[martin-fleck-at]

Changes look great to me for the most part, thank you Tobias! I'm only worried about the dependencies but maybe they are fine as well, please double check.

[martin-fleck-at]

LGTM!