In the FreeSWITCH core, the return value of switch_case_db_test_reactive
is ignored, but it is usable in LUA modules (and other bindings via
SWIG). The LUA API example[1] shows how to check the return value, but
that example miserably fails if the database did not exist before.

Changes:

 - Document the expected behavior of the test_reactive function.
 - Assert that test_sql and sql_reactive are both given. If either
   query is not given, the caller is using the wrong API.
 - When SCF_AUTO_SCHEMAS is cleared, use the return value of the
   test_sql execution. Does anybody use this? Why not remove it?
 - Do not unconditionally return SWITCH_FALSE when test_sql fails,
   instead allow it to become SWITCH_TRUE when reactive_sql passes.
 - Remove the unnecessary test_sql check for SCDB_TYPE_CORE_DB
   (this is now enforced through an assert check). (+reindent)
 - Clarify the error message of drop_sql, prepending "Ignoring" to
   the "SQL ERR" message.
 - LUA: Do not print "DBH NOT Connected" if the query fails. This was
   the initial source of confusion.

 [1]: https://confluence.freeswitch.org/display/FREESWITCH/Lua+API+Reference

Revert "depend on fs before install"
This reverts commit 6c522179.

Revert "removing commented work in progress on SDES and logging tunning on"
This reverts commit 6df5288f.

Revert "more formatting and logging tuning"
This reverts commit 0e89bbd0.

Revert "logging adjustment"
This reverts commit 764faad6.

Revert "missing host to network conversion highest_sequence_number_received"
This reverts commit 50c62cdf.

Revert "logging correction"
This reverts commit ea973b0b.

Revert "[FS-6623] implement RTCP report generation"
This reverts commit 0b7863a9.

rtcp_init

Apparently the MetaSwitch guys incorrectly interpret `Privacy: none`
as `Privacy: id`.

ref: RFC 3325
Reported-by: Stéphane Alnet <stephane@shimaore.net>

FS-6817 #resolve

Fix dates in RPM changelog that cause complaints on newer RPM build
software

When we specifically release all limits on a channel we destroy the
hash table stored in the "limit_hash" private channel data but we
don't destroy the private data as it will be reclaimed as part of the
session.  If limit increment is called after the limit release we can
reuse that channel private, but we need to check whether the hash
table is null first.  Fortunately this makes the code look better
anyway.

FS-6775 #resolve
FS-6783 #resolve