This macro has expanded to nothing for a while now and even before, the usage was misguided and unnecessary as explained in this video: https://www.youtube.com/watch?v=cjotPqQxxAY

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Still needs updates in services_thread(), CGI stuff in websrvr.c,
and sbbs_t::external()

See if this resolves rjwboys reported error:
threadwrap.h:204:42: error: expected expression before ‘do’
 #define protected_uint32_init(pval, val) atomic_init(pval, val)

Nobody's checking the return values anyway.

protected_*_adjust() only adjusts now.

Deal with the resulting warnings (using (void)).
Deal with the incorrect integer to protected_int* assignment in services.c
(just don't support server.clients property reading in service scripts).

Also, the strcpy()->SAFECOPY() change in ftpsrvr.c was wrong, caught
by GCC warning - oops.

The Synchronet FTP server has (since 2001) disallowed PORT/EPRT/LPRT commands with a "reserved" port number (i.e. < 1024) as recommended by RFC2577 and when attempted, would log a "SUSPECTED FTP BOUNCE HACK ATTEMPT" in the data/hack.log file.

However, as Karloch (HISPAMSX) pointed out recently, an FTP Bounce Attack to other TCP ports was still possible (and detected/reported by some security scans as a potential vulnerability).

So, reject all PORT/EPRT/LPRT commands that specify an IP address other than that used for the control TCP connection unless the sysop specifically enables the new "ALLOW_BOUNCE" option flag (in the [ftp] section of sbbs.ini) and the user is an authenticated non-guest/anonymous user. And as before, log the attempt as a suspected hack attempt.

This change also removes the "Directory File Access" checkbox from the Synchronet Control Panel for Windows as that feature is "going away" soon (or at least, it won't be an FTP-specific option/feature if it remains).

The Synchronet FTP server has (since 2001) disallowed PORT/EPRT/LPRT commands with a "reserved" port number (i.e. < 1024) as recommended by RFC2577 and when attempted, would log a "SUSPECTED FTP BOUNCE HACK ATTEMPT" in the data/hack.log file.

However, as Karloch (HISPAMSX) pointed out recently, an FTP Bounce Attack to other TCP ports was still possible (and detected/reported by some security scans as a potential vulnerability).

So, reject all PORT/EPRT/LPRT commands that specify an IP address other than that used for the control TCP connection unless the sysop specifically enables the new "ALLOW_BOUNCE" option flag (in the [ftp] section of sbbs.ini) and the user is an authenticated non-guest/anonymous user. And as before, log the attempt as a suspected hack attempt.

This change also removes the "Directory File Access" checkbox from the Synchronet Control Panel for Windows as that feature is "going away" soon (or at least, it won't be an FTP-specific option/feature if it remains).

Don't return an error if the node#/node.cnf file can't be opened for all uses of load_cfg() except from the terminal server. This fixes #214 for Tracker1

We were just trusting that the error strings would be shorter than 256 (usually), but since we're including paths and strerror() results, we really have no control over the length of the error strings. So enforce some healthy boundaries. This could explain the crashes that Divarin of Mutiny is seeing with SCFG on WinXP or maybe it was the truncsp(strerror()) stuff that was just removed as well. We'll see...

When a user logins to the FTP server concurrently, this creates a
race condition with an/the other FTP session that may be creating/
downloading a QWK packet. On Vertrauen, this results in the
occasional error removing the file since it was removed unexpectedly:
!ERROR 2 (No such file or directory) in main.cpp line 2747 (event_thread) removing "/sbbs/data/pack1111.now" access=0

Set the client protocol to "FTPS" upon successful TLS startup in the control connection (response to the AUTH TLS command from the client). Log some messages indicating FTPS was attempted or successful.

This seems to be misguided and would only increase the chances of a DoS-type attack on TCP session resources.

A second 3-second delay upon malloc failure is also removed.

Support optional limit on concurrent connections from the same IP address to the FTP server by setting MaxConcurrentConnections in the [ftp] section of sbbs.ini. Unlike the mail server and the terminal server, this concurrent-connection count is not discounted by the number of authenticated logins. The default value is 0 (unlimited).

This closes issue #156

The days of browsers rendering HTML served-up via FTP are over, so remove this feature. This also removes all JavaScript support from the FTP server and that is a bit odd as it was one of the first Synchronet components for which I added JS support.

Removing this feature was pretty painless; much easier than adding it was. The main motivation was less cruft to port to the file base in the works. There should be no more references to 00index.html anywhere at this point. Bye bye cool feature, we'll miss you.

Recompiling ver.cpp only now, so need link ver.obj/o with the various targets now. I'll need to update the objects.mk for the *nix builds, next.

The argument to JS_NewContext that we were allowing to be configured was not the contest stack size, but rather:
"The size, in bytes, of each "stack chunk". This is a memory management tuning parameter which most users should not adjust. 8192 is a good default value." - per Mozilla.

So we're just going to use the suggested default, hard-coded.

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

Probably only a problem on Vertrauen, but some QWKnet nodes, for some unknown reason, like to FTP-connect multiple times concurrently and request to download a QWK packet. This creates a race condition where the QWK packet gets created/downloaded/deleted before the second FTP connection can successfully download the same file, thus logging an error "opening file " on the server (VERT). So if the pack*.now file already exists, reject the download request. "What are doing?" is what I really want to ask these nodes, but better just throw them an error response and quietly move on.

active_clients is destroyed in cleanup(), so it must be re-initialized inside
the server init/recycle loop.

Fix reported and observed crash in cleanup() (in ftp, mail, websrvr)
when failing to create the temp directory. This was due to cleanup()
being called before the protected integer "active_clients" was
initialized.

Also, md() needs to return the errno value (not a BOOL) since the
caller may be in another DLL with a different errno (which likely
has a value of 0/no error).

... in other non sbbs.dll modules (e.g. *srvr.dll).

So now log error messages elsewhere where appropriate.

DLL-exported and optimized md() a bit.

Eliminate the hack in each server where it will over-write startup host_name
(with the configured Internet email address), if it's blank. This hack was
subject to a race condition where the parent app (e.g. sbbsctrl.exe) would
clear or re-initialize the host_name after the sever threads had initialized.
Instead, just use a function which will return either the startup->host_name
or (fallback to) scfg.inet_addr.

More file existence/length checks, with only a WARNING log level (not error) since some QWKnet nodes apparently like to start concurrent QWK packet downloads and inevitably one finishes first, deleting the file, and the second transfer logs and error. Examples:
  8/14  08:10:06p  2296 <EPHRAM> downloading QWK packet (1320 bytes) in passive mode
  8/14  08:10:06p  3792 <EPHRAM> downloading QWK packet (1320 bytes) in passive mode
  8/14  08:10:06p  2296 <EPHRAM> DATA Transfer successful: 1320 bytes sent in 0 seconds (2640 cps)
  8/14  08:10:06p  3792 <EPHRAM> !DATA ERROR 2 (No such file or directory) line 1376 opening s:\sbbs\data\file/0888.qwk
  8/14  11:28:55p  2576 <POTOGOLD> downloading QWK packet (27129 bytes) in passive mode
  8/14  11:28:55p  2576 <POTOGOLD> DATA Transfer successful: 27129 bytes sent in 0 seconds (54258 cps)
  8/14  11:28:55p  1924 <POTOGOLD> downloading QWK packet (4294967295 bytes) in passive mode
  8/14  11:28:56p  1924 <POTOGOLD> !DATA ERROR 2 (No such file or directory) line 1376 opening s:\sbbs\data\file/0168.qwk

Also some more 64-bit file length support (flength returns an off_t now, not a ulong).
And ftell() returns a long (not a ulong).

The problem: the sysop (me) is not notified of critical errors (e.g. synchro.net zone file problems) in a timely manner.
Part of the solution: notify a configured user (e.g. user #1) via short-message/telegram and email/netmail logged-errors when messages of a configured severity (e.g. "Critical") are logged.
The second part of the solution (coming next) will be allowing timed events to log a message of a configurable severity logged when the event fails (returns a non-zero error level to sbbs).

I'm saving the error-notification-user-number and log-severity as part of the node.cnf file because:
- that's where the validation user number is already set
- I can conceive of a large system were certain node ranges (different instances of sbbs) might want different operators to be notified of logged-errors

This also means I eliminated all the legacy com port/modem stuff from the end of the node.cnf file. None of that is used in sbbs v3.

Also included in this commit are improvements around logging:
- reduce the severity of UDP recvfrom failures in services
- a more detailed log message when the mail server successfully delivers an email (via SMTP) - easier to answer the question: was that email you/they sent delivered successfully?

messages (telegrams) from 128 to 256 bytes to resolve observed truncation of
download notification messages like this:
"Guns N Roses - Hotel Brawl Jam (Live).mp3 was FTP-downloaded by Guest [89.245.6.
199]
You were awarded 2,057,356 cred"

together to keep things atomic:
1. Eliminate eprintf() as sbbs_t::lputs() and sbbs_t::lprintf() do the
   "right thing" (e.g. log to the event log when called from the event_thread).
2. Moved upload_stats() and download_stats() from ftpsrvr.c to getstats.c where
    I plan to make use of them for JS-based upload/download file support.

is actually an authenticated local user (when usernum != 0).

msg_client_hfields() no longer saves the client->user as the SMB SENDERUSERID
hfield when the client hasn't been authenticated (as is the case with normal
SMTP). The SENDUSERIDs were redundant and misleading for unauthenticated
SMTP-received mail messages, so that's now fixed.

(ctrl/node.dab) is constantly closed and re-opened for every non-locking read.
This is really slow across network file systems and unnecessary, so use a
similar optimization as the C++ sbbs_t class where the file can (and normally
is) left open across multiple consecutive reads.
Create/use opennodedat() function.
Uses the new CLOSE_OPEN_FILE() macro from xpdev/filewrap.h.

resolved host-name on "Hostname:" log lines.