Since v3.19 (the new filebases), when a user FTP-downloaded a file, we failed
to properly find/load that file's record from the filebase (searching for the
file's full path, rather than just the filename), so the code the increments
the file's download counter, notifies the uploader, awards credits, etc. did
not ever execute. This means that FTP-downloads for all files downloaded via
FTP were effectively "free" (and nobody noticed). No error was logged either.

I discovered this while debugging the case of "(null)" filenames in the
action/download MQTT topic messages being published by the FTP server. So
that issue is fixed as part of this commit as well.

Oh, and if this code had executed before, it would have memory-leaked the
file information, so that's fixed too (added call to smb_freefilemem). Ugh.

Be sure to let them select a node even when no nodes are technically "in use".
As requested by Nelgin in IRC (what, no gitlab issue?)

Looks like just a confluence of search/replace errors over the past 19 years,
starting with commit 9ef382e5.

A sysop can, and may want to, chat with a user before they succesfully login.

On the node options popup menu, these options weren't visible/available unless
there was a user logged-in, but they're usable and useful even when there
is not a user logged-in.

e.g. "action/hack/smtp login" -> "smtp_login", best practices and all.

e.g. 20230130T171211-480	0	<unknown user>	76.89.231.66	<no name>

the user number name actually *are* known at this stage

This was a bug if the user had set their terminal to swap Delete and Backspace keys while not using a PETSCII terminal.

- Most published messages (besides log entries) have a timestamp (in ISO8601 format) prepended and tab-separated
- The order and number of elements in client messages (list and activities) has been updated, now includes user number
- Server client lists are now published to .../SERVER/client/list
- Server client activities (connect, disconnect, update) are now published to .../SERVER/client/action/#
- Server client count is now published to .../SERVER/client (with the maximum client count, if applicable)
- Server states are now just represented by name (e.g. initializing, ready, stopping, stopped) and not number
- BBS errors are logged to sbbs/BBS/action/error/LEVEL (where LEVEL is the log level name, e.g. "critical" or "error')
- All server hack-attempts, SPAM attempts, logins, logouts, uploads, downloads, are published to sbbs/BBS/action/ACTION/*
- Chat pages are published to sbbs/BBS/action/page/node/#
- New users (on the terminal server) are published to sbbs/BBS/action/newuser
- Posted messages and executed external programs (on the terminal server) are published to sbbs/BBS/action/ACTION/CODE topic
- The event thread started/stopped status is published to .../SERVER/event

Yeah, the wiki will get updated soon to reflect/document all these changes

I noticed that the node status displayed by load/presence_lib.js (e.g. used
by exec/nodelist.js) would have (N) for node-message waiting instead of (M)
as is reported in other places (e.g. the node utility, umonitor, sbbsctrl).
So this commit commonizes this behavior.

Now, it's crazy that there are (at least) 3 places that this node status
display is implemented and more things should just use nodestatus() to get
that string, but I'm not solving that copy/pasta issue in this commit.

The interactive prompting for terminal capabilities worked fine,
but the default configuration menu settings did not reflect the
user's previous choices and changes they made (e.g. toggle mouse
support or BS/DEL key swap) were not reflected in the menu. Once
logged in, the normal user defaults menu worked as expected. This
is all because term_supports() keyed off of SS_USERON which isn't
set during new user sign-up, so let's key off SS_USERON|SS_NEWUSER
now.

The previous (reverted) change to SAFECOPY would double-resolve the (src)
argument and caused weird side effects.

Again, removes SAFECOPY_USES_SNPRINTF since it was unused.

This reverts commit 13d44e3b.

Resolves CID 434888, not sure why this one didn't show up before.

In a fresh v3.20 install, the legacy stats files don't exist, so don't try
to convert/upgrade them and log errors about it.

malloc(0) returns a usable/freeable pointer on all supported platforms.

This change insures that the scfg_t dynamically allocated arrays are all valid
non-NULL pointers, even if/when the array length is 0. This should resolve
a lot of new(ish) CIDs. Or not. We'll see. :-/

Not as flexible with regards to formatting as xpDateTime_to_isoDateTimeStr()
but simpler to use (with a time_t source).

This should resolve (new) CID 434884 and 434885.

Also, remove the SAFECOPY_USES_SPRINTF check/block - nobody enables this.

This fixes issue #495.

The sub_t.subnum's that were being updated as message areas were being saved to
msgs.ini could not be used as an index into the scfg_t.sub array at this point
(the subnum would be the new index position when the msgs.ini was re-read/loaded)
.

This was not an issue in v3.19 because we just saved the subnum (to msgs.cnf) and
in v3.20, we save the sub's internal code (to msgs.ini) and were using the newly
updated sub_t.subnum to find the corresponding sub_t for that internal code. Since
the subnum is not used now during the save process, no need to update it here
(this reverses part of the commit 11e529d4 from 5 years ago).

This fixes issue #502 - thanks to the irc.synchro.netizens that reported it!

IF user hits 'Q' (or whatever the "Quit" key is), set the default protocol
field in the user record to " " (instead of an empty string).
If user hits abort (Ctrl-C), don't make any change to the default protocol.

A blank download protocol field in a user.dat, when parsed, sets the 'prot' field
of user_t to 0. When writing the record back to the user.dat, this would prematurely
truncate all other fields off the user record (since strings in C are NUL terminated
and we're using sprintf() to format the record and %c specifier for that field).

The fix is to write a ' ' character instead of '\0' if the user_t.prot is '\0'.
As part of this fix, I'm writing a '?' if a user_t.sex is '\0' (not sure if this
is actually possible, but just as insurance). Those are the only 2 single-character
user properties/fields today.

Bug reported/debugged by Al of The Rusty Mailbox (1:153/757.2) - thank you!

This function has been causing somewhat rare crashes (e.g. one per week on a very active system with MQTT enabled) on both Windows and Linux (see issue #495). The root-cause is still unclear (possible heap corruption?). This function needed more robustification anyway (see previous TODO comment), so I'm refactoring here to no longer use strListAppendFormat, which uses vasprintf (the function where the rare crash was occurring) and instead just use snprintf and strListPush. The total client_list that's published (as a single string/message) is now dynamically allocated (this was the point of the previous TODO comment). This may not actually fix the issue if there's a heap corruption occurring somewhere else in this function or the call-chain that's reaching here (usually from the web server).

Another change to mqtt_client_on(): don't incremented the server's 'served' counter until client disconnects (this is a past-tense statistic).

Also:
- mqtt_pub_strval() can now accept a null 'str' argument which is effectively the same as mqtt_pub_noval(), so the pub_noval() function is now just a thin wrapper around pub_strval().

- mqtt_startup() now clears the client_list topic and sets the client_count topic to 0.

Reduce occurrences of subsequent errors (unsure of root-cause):
!ERROR 2 (No such file or directory) in main.cpp line 2778 (event_thread) removing "/sbbs/data/pack0341.now"

This does seem to be the only location that deleted pack*.now files, so weird that they'd disappear sometime after calling glob(), but I do understand that its theoretically possible.

No immediate need/use.

to remove all sections in an .ini file or all sections with a specified
prefix.

Allows for more/better wildcard matching in viewable and testable
file types and download-events (e.g. "tar.gz" or "tar.*").

This solves the "double-dot" problem in some file types/extensions.
An implicit "*." is prepended before the configured file type/extension.

If libarchive couldn't extract a QWK or REP packet, we'd fallback to searching
for a match among the configured extractable file types and if no extension/type
match was found, default to the first configured extractable file type
(even if there wasn't one) which would result in a NULL pointer dereference
and most likely a crash. Instead, if no matching configured extractable
file type is found, just log a warning message and don't continue with the
extraction attempt. With SBBS v3.19+, it's totally valid/legit to have no
extractable file types configured in SCFG and things "just work" (using
libarchive).

For Viewable, Testable, Compressible file types and download events,
the file extension is no longer limited to 3 characters. 15 characters
seemed like "enough".

Similarly, a user's temp/QWK file type preference is also extended from
3 to 15 characters.

This fixes issue #486, but file types such as *.tar.gz (2 dots in the extension)
are still an issue and will be addressed next.

... but the old user.dat fields would still just be 16 chars in size.

Also a strcpy -> SAFECOPY conversion for user tmpext.