refactor(iron-remote-desktop): use PartialObserver instead of single callback for onSessionEvent

[Alex Yusiuk (RRRadicalEdward)]

I've refactored the onSessionEvent method to use PartialObserver instead of a single callback.
This change gives the ability to pass next and error callbacks instead of only next in places like this in Devolutions Gateway Standalone

[Benoît Cortier (CBenoit)]

Before we move ahead with this change, I’d like to resurface an idea I mentioned in this PR comment: can we drop RxJS from iron-remote-desktop altogether?

Rationale:

• Leaner dependency graph: fewer transitive deps, less maintenance work tracking major RxJS releases.
• No implicit requirement for consumers: users don’t have to bundle RxJS or fight version conflicts.
• Smaller bundle size: RxJS isn't huge, but every KB matters for a web component.
• Limited upside here: our event flow looks simple enough that native EventTarget, callback function or a tiny custom emitter should suffice.

In our context, is RxJS used mainly for error propagation? SessionEvent is currently IronError | string; are we emitting any other error shapes? If we need richer diagnostics, could we extend SessionEvent (with a discriminated union) instead of reaching for RxJS?

I’m all for better diagnostics, but unless RxJS solves a real pain point, zero dependencies feels like the bigger win.
If you see clear benefits (operators we can’t replicate, etc.), I’m open to being convinced. Let’s weigh the trade-offs explicitly before committing.

If you end up agreeing with me, do you think you could work on removing RxJS instead?

Thanks!

[Alex Yusiuk (RRRadicalEdward)]

Before we move ahead with this change, I’d like to resurface an idea I mentioned in this PR comment: can we drop RxJS from iron-remote-desktop altogether?

Rationale:

* Leaner dependency graph: fewer transitive deps, less maintenance work tracking major RxJS releases.

* No implicit requirement for consumers: users don’t have to bundle RxJS or fight version conflicts.

* Smaller bundle size: RxJS isn't huge, but every KB matters for a web component.

* Limited upside here: our event flow looks simple enough that native EventTarget, callback function or a tiny custom emitter should suffice.

In our context, is RxJS used mainly for error propagation? SessionEvent is currently IronError | string; are we emitting any other error shapes? If we need richer diagnostics, could we extend SessionEvent (with a discriminated union) instead of reaching for RxJS?

I’m all for better diagnostics, but unless RxJS solves a real pain point, zero dependencies feels like the bigger win. If you see clear benefits (operators we can’t replicate, etc.), I’m open to being convinced. Let’s weigh the trade-offs explicitly before committing.

If you end up agreeing with me, do you think you could work on removing RxJS instead?

Thanks!

Hello. I think it should be possible to rewrite it to use Promise instead

In our context, is RxJS used mainly for error propagation?

Not only error propagation, RxJS is also used to introduce Observable, like in the connect: https://github.com/Devolutions/IronRDP/blob/master/web-client/iron-remote-desktop/src/services/remote-desktop.service.ts#L122
But I can try to replace it with Promise.

I already made local changes to Devolutions Gateway Standalone, considering changes made by this PR.
Can we merge this PR and release a new version of iron-remote-desktop? I will come back to removing depending on RxJS once I'm done with integrating the new packages to Devolutions Gateway standalone and finishing with https://github.com/Devolutions/IronVNC/issues/811 (Irving's waiting for it). Does it sound good?

[Benoît Cortier (CBenoit)]

In our context, is RxJS used mainly for error propagation?

Not only error propagation, RxJS is also used to introduce Observable, like in the connect: https://github.com/Devolutions/IronRDP/blob/master/web-client/iron-remote-desktop/src/services/remote-desktop.service.ts#L122

But I can try to replace it with Promise.

That's actually something I'm mentioning in my original comment:

I’m not really convinced we need Observers given that all functions provided by the WASM module are simply returning Promises / Futures. We are using an abstraction for returning many values, but we ever only return one single value. I believe we could just use Promise combinators when appropriate, and it wouldn’t change the style too much. I wouldn’t be surprised we could even improve over this actually.

It does not really seem necessary to me to use an Observable (~ AsyncIterator) because there is only a single value ever resolved at this place (this is accurately represented by Future/Promise).

I think it's then possible to remove the code heavy with RxJS combinators (akin to iterator combinators, for operation on multiple values) to a more straightforward imperative code using the await keyword.

But even if we really need something like Observable (listener/observer pattern), our usage appears so minor that the native EventTarget seems enough.

I already made local changes to Devolutions Gateway Standalone, considering changes made by this PR.

Can we merge this PR and release a new version of iron-remote-desktop? I will come back to removing depending on RxJS once I'm done with integrating the new packages to Devolutions Gateway standalone and finishing with https://github.com/Devolutions/IronVNC/issues/811 (Irving's waiting for it). Does it sound good?

Sounds good to me!