Previously, many servers and services didn't support login by real name
(e.g. issue #469) even if the sysop had that option enabled in SCFG.

Move login control settings from node.ini to system (main.ini -> login)

The 3 node toggle options:
- Allow Login by User Number
- Allow Login by Real Name
- Always Prompt for Password

... have been now moved from SCFG->Nodes->Node x->Toggle Options to
SCFG-System->Toggle Options.

If you upgraded to v3.20a before now, you'll want to double-check these
settings to make sure they're how you want them set. New upgraders that run
upgrade_to_v320.js (e.g. via 'jsexec update') will get these settings migrated
automatically.

Added some error detection/logging to upgrade_to_v320.js when failing to open
.cnf files.

Constified some more user/login related function args and return types.

Oversight probably during the new filebase overhaul in v3.19. Reported by Nelgin.

As apparently these happen a lot when a client disconnects right
away after connecting.

Need to start the MQTT init/thread-start stuff after daemonizing.

Thanks to Nelgin for letting me know this was recently broken.

I'm not sure what purpose this global variable once had, but it wasn't needed
now and it was masking copy/paste issues in some of the sbbs_t methods in this
file. Just make an 'sbbs' local to bbs_thread(), since there's where it's
legit-used.

FYI: All the Cryptlib-SSH macros assume there's an 'sbbs' in scope.

The MSS detection will set this to the best value on a per-connection
basis.  This will allow larger packets to be sent from the BBS.

If something else sets these events, and they never get cleared,
this will fall into a tight loop.

This came about through the realization that the global 'sbbs' in main.cpp
can (and was/is) hiding some copy/pasta bugs.

When the system checks for an incoming byte, if there's any pending
output, send it immediately, bypassing the outbuf highwater mark.

This allows the final non-full packet to be sent without waiting
for the OutbufDrainTimeout (default 10ms), and makes a big difference
when doing a large number of ANSI queries (send an ANSI code, wait
for a response).  There's a small but noticable placebo effect as
well that makes everything feel smoother.

This commit also cleans up the output thread where it pulls from
the ring buffer into the linear buffer to take advantage of the new
event-based ring buffers.  Much easier to read now.

Speaking of easier to read, this also includes some whitespace
fixups.

Seems to work a treat.

We've never really cared how many times the ring buffer has become
empty, how many times data was added to it, or how many times we've
been over the highwater mark.  These have effectively always been
event signalling, with extra hackiness to clear "extra" semaphore
posts.

This commit removes RINGBUF_SEM entirely, and uses events for
everything.  There's an empty event (set when the ring buffer is empty),
a data event (set when the ring buffer is not empty), and a highwater
event (set when the ring buffer has at least highwater mark bytes).

A RingBufWrite() will set data and highwater events if applicable,
and clear the empty event.

A RingBufRead() will set empty event and clear data and highwater
events if applicable.

RingBufReInit() will now set the empty event, and clear the data
and highwater events.

These are the only actions the RingBuf API will perform on the
events, it does *not* clear the highwater event on a RingBufWrite()
if the buffer does not have enough bytes in it for example, this
will *only* be done by RingBufRead() or RingBufReInit().  This
allows consumers to force specific behaviours (such as forcing
the highwater event on shutdown to prevent waiting for it).  Since
the current code was able to deal with the semaphores having
arbitrarily high counts, the existing code shouldn't have any
issue with this.

For things that want to shut something down, we're now setting both
the data and highwater events to ensure it doesn't wait for a
timeout (even for things that don't use highwater like the inbuf).
The RingBuffer API should grow a thing to do this (RingBufferFlush
perhaps?) rather than the consumers poking into the innards
arbitrarily.

Tested on the webserver and RLogin server and seems to be working
great.  sexyz builds.  It seems there's some Windows thing that
uses the ringbuffer sem for something, but I couldn't figure out
what... updated the build file, but no clue if that's broken or not
now... I'm sure DigitalMan will be happy to fix it if CI doesn't
catch it. ;)

This should allow the console object to grow a "flush" method that
will set the highwater and data events.

mqtt_thread_start() actually will fail on Windows currently because we're
using a non-thread-safe version of mosquitto.dll

This moves the mqtt thread start further up before some *nix-specific stuff,
so hopefully that's not an issue.

By moving mosquitto_will_set() call into mqtt_connect().

I'm still having the issue that the LWT is being published after mosquitto_disconnect(), even though I set the "force" parameter to false in the call to mqtt_loop_stop()

It seems Linux has deprecated siginterrupt(), and they've been
aggressive about removing deprecated C functions lately.

Add some more "status" topic values while initializing and terminating.

This can be used to clear a 'retained' topic (of any type).

<host>/error
.../spam
.../hack

Set "last will" to publish the "disconnected" status.

This is to avoid the error reporting/logging that results.

This is not enabled by default.

(minimum severity of log messages that will be published via MQTT)