So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce):
result of comparison of constant 100000 with expression of type 'uint16_t'
(aka 'unsigned short') is always true

Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could
have just lowered the UIFC max number of config items to 65535, but that would
have been too easy. And why are these compared-with values of type uint16_t to
begin with? Because most ctrl/*.cnf lists (of configuration items) were
limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf
files aren't used, we could just increase these scfg_t.*_total type sizes from
16 to 32-bits, yeah? The result is this commit.

I went to (signed) int so we could still keep -1 as the special illegal
sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the
email message base). Theoretically, 2 billion configuration items could be
supported in these lists, but SCFG will limit you to 100000 anyway. So there's
a whole lot of s/uint/int in this commit.

I'd be very surprised if this doesn't result in some new GCC/Clang warnings,
but at least the old "comparison of constant 100000" warnings are now gone!

C allows char* p = '\0' (which is clearly wrong)
C++ does not.

format specifies type 'unsigned short' but the argument has type 'unsigned int'

"unary minus operator applied to unsigned type, result still unsigned"

Even though this same code compiled and worked as expected with GCC.

I'm doing builds for my jail (which doesn't have libmosquitto) on
my system that does have it now, so I need to disable it manually.

Mostly (all?) about unchecked return values. Unexpected failures to read or
write some files could've definitely led to some weird bugs.

Or even weirder, u_long?

And dereffing a ulong/u_long pointer where you expect to find an IPv4 address?
Yet even weirder still.

Fix that spit: It appears in_addr_t is defined on all platforms (?), so use
that type instead.

No known sightings of these sites actually being the location of a segfault,
but as we learned from the segfaults in rblchk(), the first entry in the
h_addr_list can be NULL in some cases.

I'm not sure why this one only started popping up now, but h_addr_list is a
NULL-terminated list and it makes perfect sense that the first entry could
be the NULL-terminator.

gethostbyname is obsolete/deprecated and we should address that in a separate
commit.

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

Apparently the mosquitto.h won't always be installed in /usr/include on
all systems (e.g. Deuce's FreeBSD gitlab-runner system)

It was redudnant having "External Editors" under "External Programs" (they're
all external, yeah?) and of course, "Editors of what?"

So yeah, existing docs are now all wrong. :-)

Keyop reported an issue via irc whereby a user that failed to download a file
would leave the node "hung" in "downloading via telnet" node status even
though the user had long since disconnected and the log reflected that the
terminal server was aware of this:

term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 4 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 4 connection reset by peer on send
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 disconnected
term Node 4 !ERROR 32 sending on socket 102

and

term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 3 connection reset by peer on receive
term Node 3 !ERROR 32 sending on socket 96

These nodes were then locked up in call to passthru_socket_activate(false)
as reported by gdb, e.g.

Looking at passthru_socket_activate(), the deactivation path (called at the
end of external() in this case), it was clear that this could be an infinite
loop in the case the user had disconnected:

    do { // Allow time for the passthru_thread to move any pending socket data to the outbuf
        SLEEP(100); // Before the node_thread starts sending its own data to the outbuf
    } while(RingBufFull(&outbuf));

These flush/purge loops aren't strictly needed if the user has disconnected,
but as can be seen by the above logs, the terminal server may not know that
(the socket may not indicate disconnect) before passthru_socket_activate()
is called by external().

So... worst case, just do the activation and deactivation buffer flushes
and purges for 60 seconds.

"I can't think of a reason I'd want scfg and echocfg to remain windows (gui) programs"
                                              -- Digital Man

While I'm here, hack up some SyncTERM vcxproj stuff (which almost
certainly doesn't work, but since I can actually test it now, I
may as well try)

... or else any pending published messages aren't sent.

Some shell pwd implementations default to the "Logical" PWD, which
can contain symlinks.  The POSIX standard for /bin/pwd is to return
the "Physical" PWD with all symlinks resolved.  Some shells don't
support the -P option the the built-in pwd, so we don't want to
reply on that.

For some reason, we're redefining the PWD env variable which should
by the phyical path, but I'm not really interested in tracking down
all the windy history for this.

Basically, this bit me once, and now it's fixed.

It's unclear whether trailing whitespace is supposed to be significant or not
(FidoNet specs don't say), but I don't see any reason why "John Doe" and
"John Doe " should be considered unique senders or recipients. Remove any
trailing whitespace from message subjects too.

This change makes the trailing whitespace truncation in SMB hash functions
unnecessary (at least for SBBSecho-imported messages), but most (all?) other
message transports don't allow for this nonsense in the first place.

Log a warning message when either the "local" or "in-transit" flag has been
stripped from ("Sanitized") imported packed-messages.

Keyop reported a chksmb warning on a FidoNet message that contained the
'in-transit' attribute:
<Keyop> Message flagged as 'In Transit'     (?): 1
<Keyop> fidonet_fidosoft Message Base has Errors!

The message in question appears just to be a corrupted echomail msg coming
from HPT:
Sender           '56:43 '
To               Tommi Koivula
Subject          test
X-FTN-AREA       FIDOSOFT.HUSKY
X-FTN-TID        hpt/os2-wc 1.9.0-cur 2021-03-14

SBBSecho didn't use to convert/import the "in-transit" flag on imported
netmail or echomail messages, ... until commit 446ab0ef, which
was needed to support the TickFix robot. So now, let's just sanitize the
packed-message attributes a little sooner in the import process and log a
warning when such sanitization has taken place.

The notification of offline users was removed from the mail server 13 years
ago (commit 729eb16b) without a lot of fanfare or explanation. Add an
option for notification of offline users (in addition to online users) for
those sysops that want that behavior.

Use the userdat is_user_online() function in place of the getnodedat() loop,
which also wasn't considering nodes in "logon" status as having a user online.

Contrary to https://mosquitto.org/api/files/mosquitto-h.html#mosquitto_loop_stop, passing force=true is not enough for the mosquitto network thread to end, mosquitto_disconnect() must be called.

JSDOC fix-ups.

Mostly just bitfield->bit-flags.

A little more visiblity into the MQTT library (version, function return values)

Recently started truncating trailing whitespace from sender/recipient names
before calculating the CRC value (similar to what we do for message subjects
as of a year ago). To suppress errors when evaluating messages (with trailing
whitespace in sender or recipient namems) created or imported before this
change, use this new -N option.

And don't offset long(er) windows from edges to allow more options to be
on screen at once.

Tested with 50 column mode.

Fixes Windows build.

Right now, only supports publish, subscribe to come next.

Only included with the mosquitto lib support is enabled in the build.

No functional change, just a little clean-up.