Removed the reference for invalidateCookie, since it doesn't exist anymore.

Since Meteor was split in multiple process and events started to be
filtered by instances, all Etherpad's Redis events were being discarded.

Etherpad has a Redis' publisher plugin that is unaware of BigBlueButton's
existence. All the communication between them is kept simple with minimal
of internal data exchange. The concept of distincts subscribers at Meteor's
side broke part of this simplicity and, now, Etherpad has to know which
instance must receive it's messages. To provide such information I decided
to include Meteor's instance as part of the pad's id. Should look like:

 - [instanceId]padId for the shared notes
 - [instanceId]padId_cc_(locale) for the closed captions

With those changes the pad id generation made at the recording scripts had to
be re-done because there is no instance id available. Pad id is now recorded at
akka-apps and queried while archiving the shared notes.

I was shown a case just now where `CreateNewPresentationPodEvtMsg` can happen prior to the full add of a meeting. This log line becomes relevant once again

Disabled `'Backend meeting queue had not been initialized'` which was added to pinpoint an issue with handling of meeting create events, but the issue seems to be unrelated (and has not been hit after resolving a memory leak)

* moving locales folder to /public and applying changes needed to serve locales as static files

* better dev/prod check

* transifex pull script changes to match new locales directory + ignore locales with less than 100 lines

* fix local/prod locales path

* merge fallback messages

* applies new locale changes to legacy client

`bbb-html5.nginx` file content should also be changed to the following:

```
location /html5client/locales {
  alias /usr/share/meteor/bundle/programs/web.browser/app/locales;
}

location /html5client/compatibility {
  alias /usr/share/meteor/bundle/programs/web.browser/app/compatibility;
}

location /html5client/resources {
  alias /usr/share/meteor/bundle/programs/web.browser/app/resources;
}

location /html5client/svgs {
  alias /usr/share/meteor/bundle/programs/web.browser/app/svgs;
}

location /html5client/fonts {
  alias /usr/share/meteor/bundle/programs/web.browser/app/fonts;
}

location /html5client {
  # proxy_pass http://127.0.0.1:4100; # use for development
  proxy_pass http://poolhtml5servers; # use for production
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
}
```

Depending on the sequence of events on the server, user sometimes is
added to the users collection with the name information, and sometimes this
information is updated in a second moment. Once we need the username
to show the push notification, we observe changes on this field for both
added and changed event.

Closes #11307

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

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

Also removed unnecessary fields

Co-authored-by: Anton Georgiev <antobinary@users.noreply.github.com>

Complements #11533

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

Locales would be fetched even if you simply open and save settings window (without changing any setting)
We now test it similarly we do on 2.2
Closes #11318