Should fix CID 515599 since this seems to be the only place we call
unlocknodedat() without possibly not owning the nodefile_mutex already.

getnodedat() now performs a non-locked read by default.

Perform more checks of getnodedat() return value before calling putnodedat()
to avoid unintentionally zeroing out node.dab records.

Add/use unlocknodedat() method for unlocking a node.dab record without
writing.

Note: The userdat.c getnodedat() and putnodedat() still return int (i.e. 0 on
success), so that can be confusing.

Can't backup (make copies of) an open file.

Configured in SCFG->External Programs->Fixed Events and the Node Daily Events
configured in SCFG->Nodes, now can be disabled (without just clearing the
command-line) and toggle-on "Native", so the program doesn't have to be added
to the dreaded "Native Program List" in order to *not* be treated as a 16-bit
DOS program (the default).

Eventually I'll allow multiple of each time of system fixed event, but this
is an improvement for now at least.

This date (basically 0) means either the dsts.ini file doesn't exist or there
was an issue reading it successfully (that was not detected by getstats()).

True, a sysop could add/configure a monthly timed event instead, but that
requires more configuration. Fixed events are nice in their simplicity.

This is intended for running the new Synchronet trashman utility, but could be
used for anything that's simple to execute and the sysop:
- doesn't care which node/instance of sbbs it runs from
- doesn't care exactly what time the event runs
- doesn't need the assorted options available for timed events

Trying to get to the bottom of user.tab corruption (issue #797).

Created sbbs_t::batch_upload() and JS bbs.batch_upload()
returns true if one or more blind-uploads were received and all files in
the batch upload queue (if any) were received

The Rainbow Ctrl-A codes (x|X) are not valid for message (there's no universal
ANSI equivalent) - so treat as "invalid Ctrl-A codes" for most (message) uses.
e.g. they're stripped when entered into text with the internal message editor.

sbbs_t::chkpass() and JS bbs.good_password() now default to *not* requiring
the password to be substantially different from the user's current password.
This fixes weird issues where a user that just wanted to add more characters
to their current password woudl not be allowed by cause the new password was
"too obvious"
JS bbs.good_password() now accepts an optional second argumnet: forced_unique
which defaults to false.
sbbs_t::chkpass() (JS bbs.good_password()) would always return false if the
provided password was the same as the user's current password, regardless of
the 'unique' parameter value. Now, only reject unchanged password when unique
is true.

sbbs_t::upload() and JS bbs.upload_file() now accept an optional second
argument: 'filename' which when specified, the function won't prmopt for the
user-supplied filename.

New JS property: file_area.max_filename_length

file_area.min_diskspace, settings, and web_vpath_prefix are now read-only.
These properties should not have been writable.

Fix for CID 509720

Part of potential fix (or work-around) for issue #791

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

If user is being kicked off for being on "More than one node at a time", then
don't send a message to other any other nodes that the user logged-on
successfully (they haven't). Previosuly, it'd send messages to all the
lower-numbered nodes that were in-use (but not by the same user).

Reported by Nelgin.

It's possible for a sysop to allow message creation before logon (e.g. a login
matrix mode).

Eliminate the use of netmail.msg as a temporary message input file (not sure
why this has stuck around for so long).

I don't recall this actually being a thing, ever, so certainly no reason to
be cleaning these files up during logon. <shrug>

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.

Note: format specifiers (e.g. %s) cannot be combined with @-codes (use one or
the other, not both).

Fixes issue #696

If you need additional text strings to support @-codes, you'll have to specify
them explicitly in feature request issues.

The Global Login Requirements (default: blank) are used for any sever that doesn't have it explicitly set.

This resolves issue #666 (the issue of the beast) for Keyop

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.

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

This reverts commit 5f1ab933.

Wrong commit reverted. Oops.

This reverts commit 4a83f908.

We're already passing a sock_init callback (ls_cb) which is supposed to set
the socket options (call set_socket_options), so this change shouldn't be
necessary and reportedly caused more issues binding ircd sockets when running
ircd.js via jsexec (though I didn't see this myself).

I saw my logon.jsonl file getting cycled multiple times a day recently on Vert
and suspect this function call may have been failing.

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.

Does exactly the same thing, no change in behavior and unlikely there's any change in performance.

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.

Will track the user's last succsesful file-download transfer rate
in characters (bytes) per second.

I'm not calculating or storing this rate yet, but will be soon. This
will make the file download ETAs more realistic and no longer
hard-coded to 3000 cps (which now defaults to 10000 cps, to keep up
with the times).

New field added to user.tab placed adjacent to the other File xfer stats,
which means the leech attempt counter (likely always 0) was moved to the end
of the user record.

If a user doesn't have access to download a file that's in their batch queue, remove it without saying anything to the user (but log a notice-level message about it) during logon. Files that no longer exist in the filebase are treated the same way.

Mostly [s]printf format fixups

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.

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

*/dsts.dab (daily statistics and running totals) -> */dsts.ini
*/csts.dab (cumulative statistics / log) -> */csts.tab

* dsts.ini now has both daily and total stats for all fields (not just timeon and logons).
* dsts.ini is now an easily modifiable text file - no longer need dstsedit (here-by deprecated and soon to be deleted)
* dsts.ini and csts.tab support 64-bit upload/download byte stats and are very extensible for future fields to be added or extended > 32-bit (this was the main inspiration for this overhaul, but it was overdue and already designed for v4, pretty much)
* csts.tab is a tab-delimited fixed length record format suitable for easy import to a spreadsheet program or parsing with scripts. Each day is a 128-character LF-delimited record with tab-delimited fields of plain ASCII text.
* All fields except timeon in dsts.ini files are updated immediately and by more non-terminal servers (e.g. post statistics from web UI scripts).
* New user stats are tracked more than just for "today".

The upgrade of these files is automatic and built-into SBBS.

Still to do: overhaul the slog utility to support the new csts.tab file format.