It is safer to look at subscriptions's state to users instead of depending
on the initial state of the collection at mounting time. Although
i couldn't force any race conditions on this, there's a chance it could
happen. The fix avoid this problem.
This complements #11533
Replaces the PR #10604, which has been temporarily fixed a problem in 2.3a2, that is, the slide size gets crazy when turning on and off fullscreen mode. Since #10604 was just a workaround, I tried to fix it in a way making more sense.
### Closes Issue(s)
closes#10459 (already closed by #10604) and #10589
### Motivation
#10604 is fixing the problem by calling "slide change" event, although the slide has not been changed actually. I tried to fix the same problem by adding a "full screen change" event listener in the layout manager, which I think is more elegant.
Debounce could make the behaviour of "not always ringing when a guest
enters" feel "buggy". Throttle makes it clearer that it happens to
prevent it from ringing too frequently.
Also move Throttle time from magic number to constant for
a meaningful variable name.
Both debounce or throttle could be used to prevent a spammer from
annoying the moderators.
With debounce, a spammer won't even be noticed by the mods, but
there won't be new notifications for legit guests during the spam.
With throttle, a spammer could still annoy the mods, we would only make
the interval between notifications bigger.
It is a tradeoff. An ideal solution would be preventing spamming from
the same user, but probably unnecessarily complex.
When validating tokens, the dummyUser created at the beginning is set
with validated=true. This means there won't be the state change that used
to occur from validated:false to validated:true (which detects the moment
joined the meeting) , therefore the alert code that expects for this change
won't run.
To fix this for audio alerts, we now detect when user join by observing
additions in Users's collection. This is actually good because we start
observing this only once (in componentDidMount), differently we used to do,
by calling this every time the tracker was activated.
To distinguish between the user addition that initially populates user's
collection from those that happens after user join (which are the ones we
want), we store the initial state (at componentDidMount) and compare it
with new additions. If the user added is present at the initial state,
then it is an addition to populates the collection, otherwise this is a real
user addition (happened after user joined the meeting)
Partially fixes#11399
