We were just trusting that the error strings would be shorter than 256 (usually), but since we're including paths and strerror() results, we really have no control over the length of the error strings. So enforce some healthy boundaries. This could explain the crashes that Divarin of Mutiny is seeing with SCFG on WinXP or maybe it was the truncsp(strerror()) stuff that was just removed as well. We'll see...

Some old/unsupported FidoNet software (NetMgr? Squish?) reportedly parse addresses from MSGID control/kludge lines in NetMail messages to determine the source and/or destination address. This is clearly a bad idea for a lot of reasons, but to improve compatibility, let's not include the message number (or an '@') in the origaddr field for NetMail messages. This does slightly increase the chance of a duplicate MSGID being accidentally generated if the "mail" base is renumbered. No change for EchoMail MSGIDs (where dupe detection and threading still benefit from the additional entropy).
For Watchman.

<@Deuce> Just saying that if someone does the work of exit_code = {thing: function(x) { return secretsauce }); exit(); they should get away with it.

Don't use the "exit_code" property value as the return value of js.exec() unless it's a number. As reported by mlong (thanks).

Also, "exit_code" was being set to null (instead of void/undefined) in js_PrepareToExecute(). I think this was just an oversight or typo by Deuce from his commit of 5 years ago (f3256d81). Since we're comparing exit_code with JSVAL_VOID in other places to determine if it was actually set, this appears to be a long standing bug.

This was initially just done for lfexpand(), but then I realized there were a
lot of these string processing functions that just checked for VOID
(undefined) argumnet value, but not null.

When a user logins to the FTP server concurrently, this creates a
race condition with an/the other FTP session that may be creating/
downloading a QWK packet. On Vertrauen, this results in the
occasional error removing the file since it was removed unexpectedly:
!ERROR 2 (No such file or directory) in main.cpp line 2747 (event_thread) removing "/sbbs/data/pack1111.now" access=0

At the request of WitNik (BGGRSCYN)

For deon's use with Docker:
When creating new nodes (after node 1), derive the new node directory from node 1's configured directory if possible (e.g. it has a '1' in it). So if Node 1's directory is /blah/bbsdir1, then node 2's directory will default to /blah/bbsdir2. When creating node 1 (the first node), it still defaults to "../node1".

(e.g. when run as a timed event) - this bug was introduced in the "Fix sub[] property setter" crash bug fix 2 commits ago.
This fixes the "TypeError: sub.code is undefined" error.

... even when there's no private data.

Should fix "TypeError: sub.code is undefined"

The private data pointer is no longer a subscan_t*. This likely explains the reported crashes when using DDMsgReader and the most recent changes (fixes) to the msg_area object.

The following properties would only reflect the status at the time the file_area object was initialized:
    - can_access
    - can_upload
    - can_download
    - is_operator
    - is_exempt

 ... so if changes were made the user while online, for example, these property values would *not* also change to reflect the current state.

The lib[] and lib_list[] 'can_access' properties still have this flaw.

Also: Add a new "files" property to the dir[] and dir_list[] objects to report the current number of files in each directory database.

can_access/upload/download and is_operator
similar to what we already had defined for sub-boards

The following properties would only reflect the status at the time the
msg_area object was initialized:
- can_access
- can_read
- can_post
- is_operator
- is_moderated

... so if changes were made the user while online, for example, these
property values would *not* also change to reflect the current state.

The grp[] and grp_list[] 'can_access' properties still have this flaw.

Also: Add a new "posts" property to the sub[] and sub_list[] objects to
report the current number of posted messages (quicker than opening a MsgBase
instance).

Set the client protocol to "FTPS" upon successful TLS startup in the control connection (response to the AUTH TLS command from the client). Log some messages indicating FTPS was attempted or successful.

This seems to be misguided and would only increase the chances of a DoS-type attack on TCP session resources.

A second 3-second delay upon malloc failure is also removed.

Also, disable the QWK packet creation timeout edit when QWK packet
download support is disabled.

Support optional limit on concurrent connections from the same IP address to the FTP server by setting MaxConcurrentConnections in the [ftp] section of sbbs.ini. Unlike the mail server and the terminal server, this concurrent-connection count is not discounted by the number of authenticated logins. The default value is 0 (unlimited).

This closes issue #156

Each list mutex is destroyed in the call to listFree() in cleanup(). Without a call to listInit(), the mutex is not recreated and thus the lists are no longer mutex-protected after a recycle. No negative consequences were observed from this issue, but a potential issue it is (was).

Don't search more than 1500 days in the future for a next-run date match. This handles erroneous or just bizarre timed event configurations such as February-29 (once ever leap year) or April-31 (never).

Don't set to 0xff to begin with, in SCFG.

Print the Mbyte estimate.

.. when packing a QWK packet (on Win32, was always reported 0 messages per second).

A bit of redundant code cleanup, no expected functional change.

Leave it to new users to do weird stuff and define a mail-forward loop. Outsmart them and don't allow forwarding when the destination is a local address (QWKnet, FidoNet, or Internet).

Exposes the FTN BBSID value from the message header (if there is one).

Update to previous commit.

Advertise the system's QWK-ID (a.k.a. BBS ID) in exported echomail messages. This will allow correlation of avatars that were imported via SYNCDATA carried via QWKnet (e.g. DOVE-Net) with messages imported from those same BBSes via FTN.

The alternative was to have SYNCDATA Avatar messages include all the AKAs of each BBS (in the body text), but that was looking like a rather complicated solution. This approach (the BBSID kludge) seems a much simpler solution.

I still need to implement the JS side of this solution however (for avatar lookups using the FTN BBSID), but this was the first important step.

The days of browsers rendering HTML served-up via FTP are over, so remove this feature. This also removes all JavaScript support from the FTP server and that is a bit odd as it was one of the first Synchronet components for which I added JS support.

Removing this feature was pretty painless; much easier than adding it was. The main motivation was less cruft to port to the file base in the works. There should be no more references to 00index.html anywhere at this point. Bye bye cool feature, we'll miss you.

Jump the time forward (in 24-hour chunks) to find the next date/time the event will run rather than just adding 24-hours and assuming it's an event that runs every day (of the week or month) at a specific time.

Also, expose the next-run-date/time for an event as a new `next_run` property for `xtrn_area.event[]` (in `time_t` format) for easier debugging of these kinds of issues.
Also expose the error log level as a new property: `error_level` while we're here.

We only use NSPR to build libmozjs, not to build sbbs. So define our own MIN and MAX macros if they're not already defined (e.g. from sys/param.h on *nix). Such a simple can o' worms, but wormful can it was.