It's possible now for clients to easily exceed the configured max concurrent
connections limit, even though they just get an error 429 page. Let's at least
track and log when a new highwater mark is reached.

Can't backup (make copies of) an open file.

We can't send a 4xx error (ie: client did something wrong) in
plaintext on a TLS connection.

Untested beyond a basic compile check.

Clean-up the web server config menu quite a bit by condensing options.

You can also disable filebase access by setting the vpath prefix to blank.

We have this feature for the FTP, Mail, and Terminal servers (with no default
limit) but crazy abuse of my Synchronet web servers has now made this a
necessity for Vertrauen. A limit of 2 used to be considered reasonable long
ago. Today, 10 seems fair enough. Setting to 0 will impose no max-connections
per IP address (other than the total client limit per server).

Apparently JSVAL_IS_STRING() can return true even when argv[1] is out of range
(I guess I assumed it'd alwasy be NULL or VOID/undefined) and this can lead to
crash when calling JS_ValueToString() on it.

to notify sysop (user #1) that they were paged. Previously, this was
a hard-coded string. The new string in text.dat is the same, but adds
2 BELs (CTRL-G chars) and is now customizable.

Created an sbbs_t::notify() method to make this easier to use and that
method supports @-code expansion, so this text.dat string supports @-codes
(which I used).

This addresses the feature request in issue #828 (beep the sysop in the
telegram/short message, when they're paged).

1) Initialize saverobot.name since this is checked unconditionally.
   This has a side effect of initializing everything else, but name
   is the only thing that actually matters.
2) Add a bar to the global settings menu.
   Previously, if you scrolled near the bottom and selected an option,
   after changing the option, you would jump up to the last item on
   the initial screen.
3) Fix the AreaMgr Support default value to be the current, not the
   opposite of current.
4) Use the correct variable for EchoMail Relay Filtered Messages
   setting default.

We're carefully counting the errors, but never looking at the count.

Upon any node.dab lock or read failure, this code would cause errormsg() which
would often/usually end up claling getnodedat() which would block forever trying
to acquire the ndoefile_mutex (introduced in commit b9633069, I'm not clear why).

Unlock/release the mutex *before* calling errormsg().

Don't deref that null pointer

I dislike this particular code a little less now:
- no more redundant string compares
- less deeply nested if() and for() blocks
- remove added areas from the add list, rather than zeroing out the tag
- a little more common code between areas.bbs and areas.ini handling

No functional change (I hope).

"AreaFix" is a proper product name. Though it's been defunct and unsupported
for decades, we still should not confuse sysops and historians: the general
term for what AreaFix did/does is Area Management, aka Conference Management.

The sbbsecho.ini key names are unchanged and the destination netmail address
for AreaManager requests can still be "AreaFix" (though "SBBSecho" is still
supported as well).

and vice versa - so area manager requests were broken since I introduced the
areas.ini support. Oops.

I noticed through code review that these kinds of messages would be rejected
as "No commands to process.". We just needed to increment the 'cmd' counter
when parsing these options to be sure we don't think that no commands were
in fact request. -R (rescan) is not by itself a command since it requires
listed area-tags to have any effect.

... like how we do for areas.bbs files.

I'm not clear if/why these would cause the issue reporetd by
Fernando but they're definitely bugs in the areas.ini areafix
code. No impact to the areas.bbs areafix handling.

... in area manager code modified in previous commit.

It's possible the client requested binary transmit in only one of the two
directions and if so, restore just the direction that was previously *not*
in binary transmit mode to NVT mode.

This allows us to save unitialized telnet_*_option values (i.e. 0x00) and pass
those values back to request_telnet_opt() with no side effect.

Before this change, we'd always request a return to Telnet NVT (turn off
binary-TX in both directions) after any file transfer. So although a Telnet
session might be negotiated into binary mode shortly after connection
(e.g., using "telnet -8"), it would be reverted back to NVT mode after any
file transfer.

The request to turn off remote binary-TX after executing external programs
didn't actually accomplish anything since we track the Telnet option states
internally and don't send redundant requests (e.g. the change into a mode
we're already in). External programs aren't expected to send Telnet requests
anyway, so I think this was some holdover from early days of stp/sexyz
development.

Where's the compiler warnings guys?

As suggested/requested by Fernando Toledo in issue #826, you can:
1. run 'jsexec make_areas_ini.js' to export your areas.bbs file to areas.ini
   (your old areas.bbs is left in place, in tact, unmodified)
2. change your Area File in echocfg->Paths and Filenames->Area File to
   somepath/somefile.ini (e.g. "../data/areas.ini") and SBBSecho will use
   the .ini file format instead of the old AREAS.BBS format (NIH)

You can always go back to your areas.bbs file by just reverting the Area File
setting back to some other non-ini filename (e.g. "../data/areas.bbs").

Incremented version number to v3.23

Of course documentation and echocfg changes will need to follow, but this is
enough to start testing (looking at your Fernando! :-).

I tried to minimize the diff as much as possible and resisted updating
(modernizing, fixing) the very old AREAS.BBS parsing and areafix code.
The new .ini code is largely modeled after the old areas.bbs code, but oh,
xpdev/ini_file makes things so much nicer and easier.

There are no known fixes for any pre-existing area file/fix issues (including
issue #826), but it's always possible I've introduced a new issue.

Can't used designated initializers in fmutex_init() because this file is still
built with C++Builder6.

and might return before setting it to anything else.

For some reason, MSVC was initializing the time_t (second element of the
struct) to -1, not the int fd (the first element), which was initialized to
0. Weird.

The auto-remove param was only needed for fmutex(), which immediately closes
(and thus don't want auto-removal), so create an internal function that's
used by both fmutex() and fmutex_open().

This is needed for *nix where normal (i.e. not Samba-mount) file behavior
requires that we manually unlink() the file, but not until just before closing
it. So we have to keep track of the file name and the 'auto_remove' desire of
the caller. This is not necessary when the file is on a Linux-smbfs, but we
need to work as expected on normal/local *nix file systems too.

This solves atomic lock file removal for *nix, but does not gaurantee lock file
cleanup upon ungraceful process termination (e.g. crash). At least in this
particular case, Windows beats UNIX.

This reverts commit e55183c0.

fmutex_open()'s auto-remove feature doesn't work on normal/local Linux file
systems: unlink() of a file immediately removes its directory entry allowing
subsequent opens of the same file name, defeating the lock.

I had tested fmutex_open() on a Samba mount (from Linux) and it worked as I
wanted (like the Windows version does). Still searching for a good solution:
if a process terminates, gracefully or not, I'd like the file to be removed
at that time and until then, other processes or threads can't create or open
the same lock file (using O_EXCL and file locking to insure this).

Oh, so much copy/paste eliminated!

This condition caused aborting BBS operations via Ctrl-C to fail when
connecting from a traditional Telnet client using binary transmission
mode (e.g. telnet -8) or SyncTERM v1.2rc6.

The check of rio_abortable was probably enough to disable this function
during file transfers (e.g. we've had no issues with SSH file transfers
that might include byte 0x03 received from the client), but I added the
check for SS_FILEXFER system status check too, perhaps unnecessary.