client_t.protocol is no longer a pointer.

Warnings reported by gcc (Debian 12.2.0-14) 12.2.0

Don't corrupt UTF-8 strings with SAFECOPY() (use new SAFECOPY_UTF8).

Some terminals (notably, Windows Terminal) display zero width UNICODE chars
as a single column-wide space. <sigh> Auto-detect the zero-width "width"
(1 or 0) of the terminal during connection and UTF-8 auto-detection.

getstr() works a lot better now with UTF-8 strings with wide chars (e.g.
emojis), but likely much more to do.

This recent enhancement (Commit 61a3ab2d) introduced security and usability
concerns.

So I created (and am now using where requested) a wrapper for formatting
text.dat/ini strings which will automaticlaly detect @-code encoded strings
and expand/use them *only* (instead of printf %-specifiers).

This might impact issue #696 since although unintentionally, it actually was
possible to mix @-codes and %-specifier usage in certain (node status)
text.dat/ini strings, but that should not be possible now. It's either/or:
@-codes or %-specifiers, not both.

Actually tested myself this time, needed a lot more than first appearances.

Also includes a security/safety enhancement where the @-code expanded string
is *not* used as an sprintf format string. Supporting both format specifiers
and @-codes in a single text.dat string is tricky (always has been).

For Accession.

Expected to use the MSG_* @-codes in this context. This allows more freedom
of ordering the message header fields reused in this expanded string. The %s
specifiers can be eliminated altogether when using @-codes.

For Accession to play with.

In response to Nelgin's inquiry:
DigitalMan would it be difficult to add login/logoff date/time to these
messages?
Node  2: xxuserxx logged on Telnet
Node  2: xxuserxx  logged off

Now, you can just use @-codes to add that kind of thing to these text.dat
strings.

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!

One of the benefits of the new .ini format config files. :-)

This increase introduced a few potential buffer overrun warnings (all writes
to smb_t.file ?)

It's possible to use savemsg() (from JS MsgBase.save_msg()) to add a message
to a message base that's not a sub-board (not configured in SCFG->Message
Areas and not the "mail" base), but in that case, savemsg() would dereference
an invalid sub in the scfg->sub array and crash. So use is_valid_subum()
to insure the subnum is a valid sub before using as an index.

At one time, Synchronet was a 16-bit DOS project, plagued by the 16-bit [u]int, so long's were used everywhere > 16-bits were known to be needed/wanted (This is before the days of the standard sized types from stdint.h), and they've persisted.

But '[u]long int' is 64-bits on *nix 64-bit builds, 32-bits everywhere else (even 64-bit Windows builds if/when we ever get around to that), so this could lead to insidious bugs that would only show up on one flavor or the other. Since [u]int is 32-bits on everything we currently support, we'll use that instead of [u]long.

This "part 1" because I'm sure there's going to be warnings and errors from the GCC/Clang builds as a result, which I'll get to next.

- 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

This fixes issue #495.

We may want Ctrl-A sequences in the telegram subject, but not in the message
subject

Also resolved some 32 vs 64-bit 'long' issues/ambiguities that have long-remained. :-)

This commit also removes logon.lst file support.

There's a TODO block remaining in js_user.c for setting portions of a user's birthdate (e.g. just the year or month or day).

Some QWKnet vote messages are failing:
evnt unpackREP <ENSEMBLE> !ERROR 2 (No such file or directory) in qwk.cpp line 1146 (qwk_vote) writing "/sbbs/data/subs/dove-gen" access=-105 info=smb_addvote thread_back field missing

Catch this problem a little higher up (in votemsg()) and log the message's reply-IDs to help determine what's the root-cause here. Don't bother calling smb_addvote() if thread_back is 0.

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

CID 319077

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...

Thanks Mr. Executive Chicken esq. for the telephone call and bug report.

When posting to "All" or replying to a message that was posted by networked (not local) user, don't attempt to search for that username in the local user base to inform them of the posted message to them.

savemsg() is the underlying C function for saving a new message (mail or post) to a message base from several places, including JS modules. If there was no "charset" specified in the passed message header, check to see if the message body text is non-ASCII but valid UTF-8, and if it is, set the FIDO_CHARSET header field to the appropriate UTF-8 charset identifier string. This would *also* address Issue #177 reported by Michael J. Ryan. It's possible, but unlikely, that a message text would contain valid CP437 that *also* happened to be valid UTF-8. If that does happen to occur (e.g. in posted ANSI art?), we might want to revert this enhancement to savemsg() and leave to the caller's to detect/specify the charset, always.

And separate the saved/imported message text into body and tail (separate SMB msg data fields) automatically to exclude signatures from quoted text.

As requested by Tracker1.

'i' is the return value of savemg(), used to determine success or failure
(and what kind of failure) - so we can't use that for the usernumber of
the recipient.

While SBBSecho would notify local users of imported messages addressed to
them (both EchoMail and NetMail) and QWK-imported messages recently gained
the ability to notify local recipients of messages addressed to them, other
methods of posting messages (e.g. just using the normal terminal server
method, e.g. the 'P' command) or using any JavaScript (e.g. web) methods of
posting messages lacked recipient notifications. So that's now fixed.
And for JavaScript-saved local email messages too. I don't *think* this will
result in any duplicate notifications of received messages, but let me know
if you see excess/duplicate notifications.
Anonymously posted messages are excluded.
Messages posted to yourself are excluded (who does that?).

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.

Try that, Nelgin.

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?

Include a replied-to message's to field to be selected in the post-to history (arrow-up to choose strings from history).

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.

subject header fields are non-ASCII yet valid UTF-8, set the auxattr flag
indicating that the msg header is in UTF-8.
This function is used by JS MsgBase.save_msg(), so any scripts/services that
use it (e.g. nntpservice, newslink, imapservice, etc.) to save messages with
header fields that may be UTF-8 encoded will automatically benefit from this
detection. Mixing CP437 (the default) with UTF-8 encoded header fields is not
supported, so if one header field is valid UTF-8 (not plain US-ASCII), then
they had better all be either plain US-ASCII or UTF-8 or there will be
UTF-8 decoding issues when attempting to display or convert later.

object/struct doesn't have any meaningful data. Prevent this from happening:
    SenderTime       19700101000000Z
    SenderIpAddr
    SenderHostName
    SenderPort       0

characters in message headers and body text will be converted to CP437.
Also include a new field in HEADERS.DAT: utf8 = true/false to indicate that
the message headers and body text contain UTF-8 encoding (not CP437).

- bstrlen() moved to sbbs_t, accepts an option pmode argument so it can account
  for UTF-8 encoded strings correctly
- JS console.strlen() now accepts an optional pmode argument (e.g. P_UTF8)
- Renamed sbbs_t::utf8_to_cp437 to sbbs_t::print_utf8_as_cp437
- Create/use msghdr_hfield() to perform UTF-8->CP437 conversions as needed for
  printing/copying UTF-8 encoded message header fields.
- Defined XTRN_UTF8 misc setting flag. If a message editor does *not* have this
  flag, it is assumed to *not* support UTF-8. Will likely use this for UTF-8
  doors as some point too (none known to exist, yet).

fidodefs.h:47:27: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 #define FIDO_CHARSET_UTF8 "CHRS: UTF-8 4" /* FTS-5003 */
                           ^
writemsg.cpp:645:15: note: in expansion of macro 'FIDO_CHARSET_UTF8'
    *charset = FIDO_CHARSET_UTF8;

(e.g. applies to email and netmail now too).

New function (derived from sbbs_t::utf8_to_cp437()): unicode_to_cp437()
New utf8 functions: utf8_replace_chars(), utf8_str_is_valid().
utf8_getc() enhancement: val arg may be NULL (for length/validation uses).

Convert quoted UTF-8 message text to CP437 when terminal is not UTF8.

Set Fido CHRS: UTF-8 header field when posted message is UTF-8.