Fetch for server's security salt at etc's bbb-web properties file.

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.

In the case where a meeting had recording enabled (record=true on create
call) but the presenter did not start recording during the meeting,
recording processing needs to be stopped after the meeting data is
archived, but before the recording formats are processed.

In the current 2.3 code, processing is halted after the "sanity" step.
However, the 2.2 code stopped processing after the "archive" step
instead. The main difference is that the scripts in the "post_archive"
directory (which are actually post_sanity scripts) did not get run on
non-recorded meetings for 2.2. This behaviour should be preserved for
compatibility.

I have added a special exception to trigger halting processing for a
recording job without causing the entire resque job to be marked as
failed. It only causes the `schedule_next_step` method to be skipped, so
following jobs won't get automatically run. This fixes #11877

This function is useful any place you want the matched recording marks
with timestamps rebased so 0 is the start of the meeting, I've used it
for chat analysis, for example.

There is no functional change here, it only exposes the extra function
for recording scripts or dropin/post scripts to use.

 - store recording process status into a redis list. This option
   needs to be enabled in bigbluebutton.yml

Fixes a crash: undefined method `[]' for nil:NilClass
that happens when a corrupt audio file is hit.

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.

Use 127.0.0.1 instead of localhost since Etherpad only listens for ipv4.

 We still use the recording status files to externally monitor the
 progress of the recordings. Let's keep these files for now until
 we figure out a different way to track the status of the recording.

Just want to make sure that we don't get any bad filenames sneaking in
and causing havoc.

This incorporates only the audio desync related changes from #11626
* Add the aresample filter with async option to fill in timestamp gaps
* Use the libopus decoder for opus audio instead of ffmpeg's builtin
  decoder

This gives the following advantages over the previous code:

* The ffmpeg input filters are loaded from a filter "script" file instead
  of passed on the command line. This fixes some cases of recordings
  failing to process because the ffmpeg command line generated for the
  audio processing exceeded the max command line length limit. (Although
  that only really happens due to BBB bugs...)
* Use absolute positions when trimming audio segments for cuts.
  Previously segments were trimmed to the length of the segment, and the
  results were concatenated. There's some possibility of accumulated
  errors in the segment lengths causing audio desync over time. The new
  code incrementally concatenates the segments, and cuts each segment
  end based on the absolute time since the start of the meeting, to
  avoid error accumulation.

Mix screenshare audio with mics again to avoid playback autoplay problems in iOS, fixed desync with aresample

use libopus decoder and encoder, its better than built-in ffmpeg/flac
don't mix screenshare audio with mics, was generating desync with bad audio segments, encode it together with video file (TODO: needs adjustments in playback)

Recording processing using MP4/OGG temporary files, stream copy, and customizable (lower) frame rates.
Discussion from https://github.com/bigbluebutton/bigbluebutton/issues/2483

When managing Etherpad's pads, Meteor makes API calls to initiate the closed captions
and shared notes modules. The pad id was being mapped to a shorter id than the meeting
id because of a Etherpad lenght limitation.

Changed to something less guessable.

Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.10.8 to 1.11.0.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.10.8...v1.11.0

)

Signed-off-by: dependabot[bot] <support@github.com>

Fix file existence test.

PR #9857 was incomplete and did not completely fix the issues described in #9062 and #9110 (dublicate).

Collects the shared notes' HTML raw data and publishes it along with the other
recording files. The playback will fetch for this file and include an option to
display it's content over the chat.

Not sure what causes this issue, but there's nothing reasonable that can
be done to draw a shape with no thickness. Just skip it.

The indexes returned in recording events from BBB refer to positions
within a UTF-16 encoded string. Rather than attempt to untangle this in
the server (which might have a performance cost), it's easier to switch
the caption processing code to operate in UTF-16 encoding as well to
make it work consistently.

The PyICU library provides a UnicodeString type which is a UTF-16 string
similar to Java and JavaScript, but which supports all the python
indexing methods. It's fairly straightforwards to swap it in in place of
the types used previously, and works natively as an input to the ICU
line break iterator too.

Fixes #10531