I'm surprised more people haven't wondered aloud: why are all the Synchronet
server settings in this huge sbbs.ini file? Well... this kind of answers that
question: it's a hell of a lot of settings! And this isn't even everything
(several advanced/rarely-used/borderline-deprecated settings aren't included)!

As part of this change, I've replaced the old date/time display with the
current config file path/name that's being edited (more or less). This will
help when a sysop has multiple sbbs.*.ini files and makes it clear if you have
multiple sbbs installs (like me), which one you're editing at any given time.

I have not implemented any of the server setting edits (other than a couple
simple toggles) or help text yet and this does not detect changes or save them
to the sbbs.ini file, but I wanted to get this committed at this stage anyway.
If you're running sbbsctrl.exe (or maybe even gtkmonitor), then maybe this is
completely redundant and unnecessary, but I figured it was good to have these
settings in one edit find/edit platform-agnostic location anyway. Hoepfully
this will (when its done) make SBBS for *nix just that much easier for a newbie
sysop/sysadmin.

Since commit fd90eec6 (2 months ago), the Synchronet Web Server on
my Windows systems has occasionally gone into a state where every HTTP session
thread was causing 100% CPU utilization and each new HTTP session thread
would just exacerbate the problem eventually leading to complete system
instability/unresponsiveness until the sbbs instance was terminated. This was
more readily reproducible on a Win7-32 VM, but would occasionally, though
much less frequently, happen in a native instance on Win10-64 as well.

Using the VisualStudio debugger, I was able to narrow it down to this:

Each new HTTP thread (eventually, hundreds of such threads) would get stuck
in this loop in http_output_thread():

    while(session->socket!=INVALID_SOCKET) {

		/* Wait for something to output in the RingBuffer */
		if((avail=RingBufFull(obuf))==0) {	/* empty */
			if(WaitForEvent(obuf->data_event, 1000) != WAIT_OBJECT_0)
				continue;
			/* Check for spurious sem post... */
			if((avail=RingBufFull(obuf))==0)
				continue; // <--- data_event signaled, but never cleared
		}

There appears to be a race condition where this logic could be executed
immediately after the output ringbuf was created, but before writebuf() was
ever called (which would have actually placed data in the output buffer),
causing a potential high-utilization infinite loop: the data_event is signaled
but there is no data and the event is never reset and nothing can ever add
data to the ringbuf due to starvation of CPU cycles.

Uses of ringbuf's data_event elsewhere in Synchronet don't seem to be subject
to this issue since they always call RingBufRead after, which will clear the
data_event when the ringbuf is actually empty (no similar loops to this one).

The root cause just appears to be a simple copy/paste issue in the code added
to RingBufInit(): the preexisting 'empty_event' was initialized with a
correct initiate state of 'signaled' (because by default a ringbuf is empty)
but the newly added events (data_event and highwater_event) should *not* be
initially-signaled because... the ringbuf is empty. So I added some parameter
comments to these calls to CreateEvent() to hopefully make that more clear
and prevent similar mistakes in the future.

Relieved to have this one resolved finally.

Fixes CID 451020

This was needed back in the v2 days to be sure the escape sequence was sent
*after* an output buffer before might've been cleared by a user's abort/Ctrl-C
action. SYNC/ASYNC called riosync() which called rioctl(TXSYNC) and we have no
equivalent in Synchronet for TCP/IP (modern sbbs). A user's Ctrl-C will clear
all pending I/O, but won't prevent subsequent output from being sent (until
the abort condition is cleared) as used to be the case with serial I/O.

... possible loss of data (yeah, yeah, we know)

This code will do nothing if there's no user logged-in or their terminal is
not ANSI or their terminal dimensions (rows and cols) are set to specific
values (not auto-detected). This code does the same thing as calling JS
console.getdimensions(). Since it waits (up to 5 seconds) for a CPR response
from the terminal, this does potentially slow down output, so caveat emptor.

This could be used by a sysop to address issue #529.

The recently updated ctrl/sbbs.ini had MaxLoginInactivity = 10M in
the [BBS] section, which was parsed as 10 seconds rather than the
intended 10 minutes. This fixes that issue and also will now store all
of these inactivity values in duration notation. Existing values stored
in seconds will work fine since that is always the assumed/fallback unit
of time in duration keys.

Thanks for the report!

The lower of the configured maximum file size (for the FTP server) and
the available disk space minus the configured minimum free disk space
is used as the maximum file size to allow upload. Appended files
are accounted for too.

Disallow uploads when free disk space falls below minimum configured
minimum free disk space.

This fixes issue #535

- New keys in [BBS] section of sbbs.ini:
  MaxLoginInactivity (default: 10 minutes)
  MaxNewUserInactivity (default: 60 minutes)
  MaxSessionInactivity (default: none/unlimited)
- Each configured external program/door in SCFG can have its own maximum inactivity setting (or else the session max inactivity is applied)
- moved node-specific sec_hangup to system-wide/shared max_getkey_inactivity (configured in SCFG->System->Advanced)
- moved node-specific sec_warn (seconds of inactivity before sending warning) to inactivity_warn (a percentage of elapsed max inactivity before sending warning), also configured in SCFG->System->Advanced and used for both socket and getkey inactivity detection
- Renamed JS console.inactivity_hangup to console.max_getkey_inactivity (old name remains as alias)
- Renamed JS console.timeout to console.last_getkey_activity (old name remains as alias)
- Removed JS console.inactivity_warning
- Added JS console.max_socket_inactivity (current input_thread inactivity threshold)
- New text.dat string: InactivityAlert (just contains 3 ^G/BELLs by default) used for non-visual inactive-user warning

The MaxLoginInactivity setting in particular solves the problem of custom scripts (e.g. animated pause prompts) that just poll indefinitely for user input and never time-out  - these will no longer cause nodes to be tied-up with inactive/bot users at login.

You may ask yourself, how did I get here? No, you may ask yourself: why configure these socket inactivity max values in sbbs.ini? The reason is consistency: sbbs.ini is where the MaxInactivity is configured for all the other TCP servers and services.

This fixes issue #534 for Krueger in #synchronet

... to make property names more consistent (e.g. with bbs.last_node).
The old names (without the underscores) are still usable but won't appear
in JSDOCS (i.e. jsobjs.html).

This allows scripts (e.g. login.js) to have custom behavior (e.g. shortening
the maximum inactivity timeout) based on how close the current node is to the
configured last node number. There may be other uses too, but for the vast
majority of Synchronet systems, first_node will always be 1 and last_node the
same as system.nodes/lastnode. Ugh, inconsistent naming. :-(

Add some missing descriptions, fix the order of others.

Mainly capitalization, but some typos and added details. 

number rmfiles(directory, spec=*, keep=0)

Removes files and sub-directories, recursively. Use with caution!

sbbs_t::pause() and JS console.pause()...
now excepts an optional set_abort argument (default is true) which controls whether this method will set the global console-output aborted flag (sys_status&SS_ABORT in C++, console.aborted in JS) when the user hits the Quit or No key at the pause prompt.

This method now returns a bool: false if the user entered No, Quit, or Ctrl-C  at the pause prompt.

Nothing makes use of either of these new pause() features yet, but its generally better to not set/rely on global state wherever possible.

For archives with directories, the first call to extract_files_from_archive() from extract_diz() would create sub-directories in the target (temp) directory, but no files within them.

To correctly solve the original problem identified in commit 79a302f4, introduce/use a new 'recurse' argument to extract_files_from_archive() which means to recursively apply the file_list filter (if specified). Always pass 'with_path' argument as false to prevent sub-dir creation.

The JS Archive.extract() method now excepts an additional boolean argument (recurse) following the file list arguments, default is false.

Remove extra whitespace in Archive JSDOC method descriptions to be consistent with other object/class docs.

The connected TCP port detection method only worked for IPv4, so automatically
detecting a CBM/PETSCII connection over IPv6 didn't work. Thanks to Deuce's
xp_sockaddr and helper functions, this was an easy change.

service_client->client is NULL in these failure/error cases, so get the
protocol string from the service_client->service (which is not NULL) instead.

Previously, there was no good way for the caller to determine if the\
user opted (when prompted) to actually log-off or not.

No change in behavior.
Eventually would like to get rid of all the CRLF (and CLS) macro usage.

That's all these macros were doing anyway, so no change.

Does exactly the same thing, no change in behavior and unlikely there's any change in performance.

But... as rightful member of sbbs_t, thus useful from other scopes.

Should get rid of all use of SYNC/ASYNC now then.

Before now, if the sysop enabled login-by-user-number and the specified login
ID *started* with a decimal digit, it'd be treated as a user number and
converted to a 32-bit integer. This could result in weird stuff, like this
error I got today:
SMTP ... !ERROR -2 getting data on user (7000401005.gc7gg@synchro.net)

7,000,401,005 is clearly greater than the number of users in my user base
on Vert, but since 7B is > 2.1B (0x7fffffff), the number would be parsed as
a *negative* integer value and thus less than the total number of users in my
userbase.

An obvious solution would be to just turn of login-by-user-number, and for
most systems, I suggest doing that (a system is less secure with it enabled).

However, I want to leave the option for sysops (at least for now) and don't
want this weird behavior so, a login by user number now requires that the
entire login ID is just decimal numbers, nothing else, and the number is
parsed as an unsigned integer. So yes, roll-over can happen for very high
numbers (>4.2B), but in no instance will the number be parsed as negative and
thus lead to an invalid user record look-up attempt.

Previously, there was no real way to tell if the call to telnet_gate() or rlogin_gate() was successful (e.g. to display or an error message to the user), though there were error/warning messages logged for the sysop. Equivalent JS bbs object methods now return Boolean too.

Include ":port" part of address argument to bbs.[telnet|rlogin]_gate methods in JSDOCS.

Removed a bunch of extraneous (copy-pasted?) JS_SET_RVAL() calls from js_bbs.cpp. This just makes the code a little easier to grok.

These methods aren't normally needed (msg scan config/ptrs are
automatically loaded upon logon and saved upon logoff), but for users
(e.g. sysops) that can be logged-in concurrently or experimenting with
scans, these methods can be useful and I plan to expose in a loadable
module next.