Fix local echo in embedded mode

[toger5]

This fixes remote echos not appearing in the widget api. As a consequence, an event listener in a matroska widget will never receive events sent by itself withisSending() === false.

This is needed in the raise hand logic for element call. We send a raise hand and need to update the ui as soon as it is sent so that pressing the button again redacts the raise hand.

The issue is caused by the following:

• An event gets a txId assigned by the embedded client (the widget)
• This txId is tracked, so that the event can be matched once the remote echo is received. In that case the js-sdk "ignores" the remote event and instead updates the already existing local event to reflect it is send.
• Using the widget api the event gets a txid twice. once in the widget (but that txid does not get forwarded to the client through the widget api) and once while it is sent by the client.
• The event that then gets to the widget uses a different txid. The two events cannot be matched up because of the different txid's. since we do have the same evId however we still ignore the remote echo.
• We end up with an ignored remote echo that did not update the local event to be sucessfully sent.

The fix works as following:

• We track the txId of the local event.
• We block all remote echos until we get a response from the send action.
• Once we have the response form the send action we know the txId - evId relation
• We take the remote echo and update the txId to not be the one created by the cleint but by the widget matching the local event of the widget.

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[florianduros]

What issue this PR aims to fix?

[toger5]

@florianduros I updated the description to reflect what the PR fixes.

[t3chguy]

Can't we just have the other side respect the txn_id we choose instead of having to track the possibility of it changing?

[toger5]

Can't we just have the other side respect the txn_id we choose instead of having to track the possibility of it changing?

This was discussed but we concluded, that the widget should not deal with the txId selection.

• To keep the api simple
• The requirement comes from the js-sdk local echo logic which most widgets do not even use
• It would require us to update the web and rust sdk driver.

But yes that is also an option.

[t3chguy]

Please avoid force pushing once you have received review as it discards any review state and means I have to review the entire change rather than just the changes.

[toger5]

We do not squash + merge right?
So I guess it makes sense to squash all the changes before I add it to the queue?

[t3chguy]

The merge queue only uses squash merges

[toger5]

Oh we are missing an EC reviewer anyways.