With the incremental backoffs, these were super long waits for locks. Not sure
about my math there, but at 500, the total timeout was not "about 45 seconds"
but rather several minutes.

At 100, the total max retry time should be almost exactly 45 seconds:

Retries      ms-per     total seconds
  0 - 9      0          0
 10 - 19     100        1
 20 - 29     200        3
 30 - 39     300        6
 40 - 49     400        10
 50 - 59     500        15
 60 - 69     600        21
 70 - 79     700        28
 80 - 89     800        36
 90 - 99     900        45*
100 - 109    1000       55
110 - 119    1100       66
120 - 129    1200       78
130 - 139    1300       91
140 - 149    1400       105
150 - 159    1500       120
160 - 169    1600       136
170 - 179    1700       153
180 - 189    1800       171
190 - 200    1900       200!

... so yeah, 500 was way too big a number.

... trying to get to bottom of user.tab corruption reported in issue #797.

Also, don't need to seek in lockuserdat() since we always call seekuserdat()
first.

This should help identify the function(s) used when the corruption occurs.

emailfiles.js puts files here that the user requested to download "via email"
and might not have been successfully delivered and deleted. So clean-up.

Reported by Keyop (upon being auto-disconnected overnight):
!ERROR 9 (Bad file descriptor) in data_ovl.cpp line 47 (putmsgptrs) writing
"message pointers" access=0

Unfortunately, the way putmsgptrs() was written, we couldn't tell if this was
an open (data/user/*.subs file) issue or a writing issue.

So create putmsgptrs_fp() and use that from sbbs_t::putmsgptrs(), so we can
log a different error (with more accurate details) if it's a file-open failure
versues a file-write failure.

I'v been getting errors locking user.tab (for read) for a while (over samba),
so hopefully this helps. The lockuserdat() total timeout duration extends from
about 5 seconds to about 45 seconds (with an incremental back-off).

Implement the same lock-retry logic/limit in putuserdat().

If a file descriptor is passed to getnodedat() and the lock retry counter was
reached, the file would be closed, but the passed file descriptor reference
would not be set to -1. This could result in exceptions (from subsequent read
attempts on the referenced file descriptor) in cases where the node.dab could
not be locked or read by getnodedat() and was thus closed.

The set/get_node_* helper functions (used by MQTT) were not initializing the
node.dab file descriptor (i.e. to -1), so it's possible getnodedat() could
try to read from and close an invalid/wrong open file descriptor. If the local
variable happened to be initialized to a value <= 0, then, no problem, but
this is undefined behavior (UB).

Fix observed crash when shutting down services server where the client_t
protocol was pointing to a freed service's protocol description string.

This was the last pointer in client_t and should resolve the last race
conditions (memory ownership issues) with its data members.

This also resolves a small memory leak in getnodeclient() where the last
client "gotten" would have its heap-duplicated protocol string leaked.

WIPterm hasn't been supported in ages and HTMLterm was just an ephemeral
experiment.

Leave the WIP ARS keyword parsing support, for backwards script compatibilty.

The file_t struct may not have the size of the file pre-poulated, so we needed
to call getfilesize() here.

For SFTP sessions, there's no shell/terminal, so no need to run command
shells (with their input timeouts, etc.). Reflect the node connection as
"via sftp" in the node status. Handle node interruption signal. Probably more
to do here with node status/actions (e.g. it'd be nice to set the action to
"uploading or "downloading" when appropriate).

e.g. month and day reversed

(as a fall back to the full external program name).

... to determine/print the current external progarm being run.

This fixes issue #716

Still using BOOL where we need Win32 API compatibility.
Using JSBool instead of BOOL or bool where it matters.
Changed most relevant TRUE/FALSE to true/false too (though it's not as critical).

You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case.
Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case.

For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef).

I didn't convert UIFC yet.

This addresses issue #698

The year is 4 digits, so the offsets aren't the same as the other 2 supported
formats. Doh!

Thanks Max for testing!

To complete the request from: Max (WESTLINE)

  Is it possible to do a new dateformat in scfg
  In sweden we using YYYY-MM-DD format as standard.

The default will be '/'.  Technically, any separator is possible by editing
the "date_sep" value in the global section of main.ini.  SCFG allows the
most popular separators: /.- and space.

... and YYYY/MM/DD for birthdate input/display.

Now set in SCFG->System (not toggle options) and stored in the "date_fmt" key
(new) in main.ini. The old sys_misc SM_EURODATE flag is deprecated (but used
to determine the default value of date_fmt when not present).

As requested from: Max (WESTLINE)

  Is it possible to do a new dateformat in scfg
  In sweden we using YYYY-MM-DD format as standard.

Now a sysop can "perm block" a client (IP address) for a limited amount of
time rather than always forever.

Add more displays of the ip.can details when actively blocking a client.

Moved twit/trash functions from userdat.c to trash.c

I wanted a couple of features for filters (e.g. blocked IP addreses):
- expiration date, optionally (only block for a limited time)
- display details of reason for filter in log messages (at time of block)

I've been thinking for some time that these files should be converted to .ini,
but then it occurred to me that I could do a sort of hybrid where the metadata
was key/value pairs tab-delimited from the search-pattern (first text on the
line). This is backward comaptible, relatively easy to view/edit by hand, and
extensible (easy to add/remove metadata fields in the future). So they'll
remain as text/*.can files.

The maximum line length for findstr/trashcan parsed files extended from 255 to
1000 characters.

Moved all trashcan-related functions from scfglib1.c to (new file) trash.c.

For the first time, I actually tested a build on WSL *before* committing to
Git. So, this *should* pass CI the first time. :-O

Many searches are done (e.g. in the mail server, QWK import) for either of 2
strings in single file or list, so let's optimize that to a single iteration
through the file/list. This should reduce some redundant file I/O.

I do find this API a little confusing with the filename or list at the end
of the argument list, but kept it consistent with the existing single string
findstr functions (which are now just wrappers for the new 2-string flavors).

I noticed during this update that findstr() did not share the same behavior
as findstr_in_list() (feature added in commit f08f2137) whereby if all the
patterns were negative searches (beginning with '!'), then *all* the
negative matches would have to be successful (not just the first) for the
function to return true. So now findstr() behaves like findstr_in_list()
in this regard.

I also added some optimizations to findstr_in_string().

The time span over which consecutive failed logins are attempted is important

'@' is in the name.can by default and the mail server recognizes user@addr
formatted logins/attempts, so truncate at the '@' before comparing against
the name.can file to prevent false !TEMPORARY BAN (1 login attempts, ...
occurences.

'T' command from the reading messages (O)perator menu

Abstraction the twit-list usage.

Uses the new ctrl/text.??.ini files (just a few words translated so far).
Adds the new "lang" user property (to user.tab and JS User class).
The language code is the 2-3 char (e.g. ISO 639-1) abbreviation of a language.
A "blank" language property value (the default), just means to use the
ctrl/text.dat contents.
User-selected alternate language file is loaded upon logon and in the
built-in/hard-coded user default settings menu.
More on the user default settings menu:
- AutoLogin via IP option ('I') to make room for new (I) Language option.
- The cold-keys menu option was removed to make room for Language option
  (via text.dat change to UserDefaultsHotKey)
- Any options disabled via blank text.dat strings will no longer result in
  supported command keys (that could accidentally be struck with hidden
  consequences/effect)
- The user_settings.js will need similar treatment

text/menu/<lang>/* is where alternate language menu files should be stored

New UserDefaultsLanguage text.dat string (inserted before new PasswordChar
string).

The request from Nightfox and Accession via DOVE-Net was to be able to set
a user's external editor even if there's no user logged-in.

These 2 user class properties in the JS object model were a bit special in
that they *only* wrote to the user database and did not immediately modify
the in-memory copy of the user_t structure, depending on the re-reading of
the user.dat/tab file to re-populate the current user_t structure when needed.
This didn't work if the current user is user #0 (no user).

So, set the current user_t.xedit and user_t.shell accordingly whenever those
JS properties are assigned a value (a string, the appropriate internal code).

These should probably be moved (along with other node functions in this file)
to nodedat.* some day.

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!

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

When sending a user-to-user file transfer, SBBS (since v3.19) will check that
the file recipient will be able to download it (e.g. doesn't have restrictions
preventing it) and this was failing for most (non-sysop) recipient users since
they wouldn't normally meet the "access restrictions" of the user directory
(by design).

warning: format not a string literal and no format arguments

Weird this warning is happening for me with GCC 12.2 (debug or release build)

smtp_netmail_addr() - not currently used anywhere else, but may be someday.
load/mailutil.js's fidoaddr_to_emailaddr() has this same logic (for FTN addrs
at least and is now used by nntpservice.js).

Also, always pass a buffer to smb_faddrtoa() from the mail server since it's
multi-threaded and its unsafe to pass NULL (using a static local buffer).

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.

Right now, the only preference is reverse mail listings (oldest first
or newest first). These settings are only used when reading "your mail",
not any other kind of mail reading.

bbs.read_mail() now returns the user-adjusted loadmail_mode value and
this allows us to determine the user's preferences and save them after
this function/method is called. A readmail_mod can now return a number
(other than 0) and that will be used as the return value of this method.

sbbs_t::readmail() now does the adjustment of the passed lm_mode before
calling any installed readmail_mod, so if for example, deleted message
viewing is enabled by the sysop, those LM_* flags might be set now in
the argument to the readmail_mod, wherase they never would before.

There is not yet any way for the sysop to set a new user's default
mail_settings, they'll just default to 0 for now.

email_sec.js will get some adjustments to use/store the
user.mail_settings next.