Watch for a 'join' action to know when the call is connected

[robintown]

Previously we were watching for changes to the room state to know when you become connected to a call. However, the room state might not change if you had a stuck membership event prior to re-joining the call. It's going to be more reliable to watch for the 'join' action that Element Call sends, and use that to track the connection state.

Sonar is complaining about code duplication here, but I petition that we bypass the warning on this PR. The code in question describes the widget actions used by the Jitsi and Element Call widgets for joining/leaving/disconnecting from calls, and I see it as mostly being a coincidence that Jitsi and Element Call now have similar widget action APIs. I would like for the superclass Call to continue to be something that you could implement for any arbitrary widget, so I think this is a case where a little duplication is better than the wrong abstraction.

Closes #29429

Notes: Fix calls displaying the wrong connection state or not triggering a notification

[t3chguy]

Bypassing the sonar warning would mean a force merge which

1. bypasses a bunch of merge-queue only tests
2. bypasses all downstream tests

This is to be avoided.

[robintown]

Right, that's what force merging entails… do you agree with my assessment that the Sonar tool is pushing me to do the wrong thing? Or would you rather I introduce a new class between Call and JitsiCall/ElementCall in the hierarchy to consolidate the similar widget communications code that they have?

[t3chguy]

do you agree with my assessment that the Sonar tool is pushing me to do the wrong thing?

I have no opinion on that, might be worth bringing up at the Web Weekly call for discussion

[MidhunSureshR]

Suggested change

	act(() => call.setConnectionState(ConnectionState.Connected));
	await act(() => call.setConnectionState(ConnectionState.Connected));

[robintown]

When I add this my IDE warns me "'await' has no effect on the type of this expression". And looking at the type definitions I see:

    // While act does always return Thenable, if a void function is passed, we pretend the return value is also void to not trigger dangling Promise lint rules.
    export function act(callback: () => VoidOrUndefinedOnly): void;
    export function act<T>(callback: () => T | Promise<T>): Promise<T>;

So it seems to me that the React team is encouraging people to not insert await when the operation is synchronous.

[MidhunSureshR]

Looking at https://react.dev/reference/react/act#await-act-async-actfn, I get the impression that they expect you to make the callback async even if you don't await anything.

[MidhunSureshR]

Suggested change

	act(() => call.setConnectionState(ConnectionState.Connected));
	await act(() => call.setConnectionState(ConnectionState.Connected));

[robintown]

See above

[dbkr]

Sounds like we agreed to skip sonar for this one: bypassing.