Optimise MatrixRTC sender key distribution for case of single member

[hughns]

Based on top of #4453.

Optimises two scenarios:

• user is only member of call, then other member(s) joins => the user can immediately rotate the key and start using it.
• there were two or more members in the call, then the other members left => the user can immediately rotate their key and start using it.

The "doesn't re-send key immediately" test is superseded by the other test cases.

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).

[fkwp]

Just got additional input

we do want to rotate the keys on any participant change. But, the keys won't actually be sent anywhere in the case of <2 devices/participants.

so pls ignore the below :-)

user is only member of call, then one other member joins => the user can immediately rotate the key and start using it.

wondering how that would behave in case of to-device messages. In that case you can only start sharing/sending a key with N=2 -- right?

there were two members in the call, then the other member left => the user can immediately rotate their key and start using it.

I think rotating in that case is sane -- independent of a consumer just to be on the safe side. However, that "intermediate" key cannot be really used since there is nobody to send the key to in case of to-device messages.

[hughns]

I've converted to draft as this will collide with #4472