Bump to release 2.3.3

Minor update to test build

bbb-conf --status will show status of frontend and backend nodejs workers

Previously, bbb-record --rebuild was restarting recording processing
from scratch by creating the .../recording/<meeting_id>.done file. This
causes the recording to be reprocessed starting at the archive step.
However, re-running the archive step for an existing meeting is not
really supported! Ever since the segmented recording code was added, it
shouldn't /corrupt/ the recording files, but it's still not good.

And as a side-effect, re-running the archive step will re-create the
.norecord file for meetings without recording marks, meaning that you
cannot use bbb-record --rebuild to force a recording without marks to be
processed.

Switch bbb-record to restart recording processing at the sanity stage to
match the BBB 2.2 behaviour. Rather than have it insert tasks directly
into resque via redis-cli, it goes through a ruby wrapper that performs
input validation and uses the resque apis.

enableMultipleKurentos TasksMax fix

Bump to beta-5

* Delete default.pdf
* Add files via upload

This is the same fix that was made in bbb-install: https://github.com/bigbluebutton/bbb-install/pull/327/

Fix https://github.com/bigbluebutton/bigbluebutton/issues/11452

Cleaning up fonts in default.pptx, shrinking default.pdf

Updated release to 2.3.0-beta-2

Fixes: 278223b4 ("Recover 2.3-alpha3 version of bbb-conf")
Resolves: https://github.com/bigbluebutton/bigbluebutton/issues/11035

Fixes  #11418
The `connectionStatus` property was removed from the Users collection in 2.3, so the check was always returning 0 which means the cron job could potentially restart KMS and SFU while there were still active users.

there was a call of grep which failed when the config file does not
exist yet. check existance of file first.