These were problematic (crash, could corrupt filebases) and unsupported,
so just change the programs to stubs that alert the sysop that they need to
switch to using the JS versions of these utilities immediately.

Only the common/UIFC-type arguments should be passed-on.

This fixes issue #646

It also appeared that the user editor spawning wouldn't work correctly
when arguments were passed to umonitor (missing a space).

Hm.

The TEXT:<x> @-code can now be used with the text.dat string ID rather than
the text.dat string number, if preferred.

For convenience and brevity, ALL text.dat string IDs are now valid @-codes
(case-sensitive). While this functionality is redundant with the TEXT: @-code
now, if there are any conflicts between new/existing @-codes and text.dat
string IDs, the TEXT: @-code can be used to overcome such conflicts.

This should help with localization (to other languages) by using common
single-word replacements (Which, Quit, Next, etc.) in text.dat strings.

The syntax of text.ini is:
<id>: "string"
<id>: "string"

Where <id> is the named identifier of a text.dat string as seen ctrl/text.dat
and string is a literal string value (optionally, in double-quotes). Line
continuations (for long strings) are not supported: you'll just need to put
your string all on one long line (up to 1024 char string).
C-escape characters for control chars and hex-encoded chars are supported.

This should address feature request issue #644

After 90 minutes of waiting, we'll do the same abort wait (and run the event
anyway), but closing the node's socket should be enough to get the node_thread
to terminate and set the node status back to NODE_WFC.

Apparently some sysops like to leave their terminals idling (e.g. running MRC)
and never disconnect and since they're T-exempt, the BBS won't limit their
time online to allow events to run. Exclusive events will wait for all nodes
to become inactive, but give up after 90 minutes of waiting and run the event
anyway and set node status to WFC at the end. If the node was actually still
connected/in-use, this could lead to the (new) critical error messages logged
"!Node X status is WFC, but the node socket (N) and thread are still in use!"
and other chaos (NODE STATUS FIXUP and the like).

This should prevent all that by just abruptly disconnecting the node after
waiting 60 minutes for the sysop to gracefully disconnect. The log message
when this happens:
"!TIRED of waiting for node N to become inactive (status=X), closing socket Y"

Fixes unnecessary [Hit a key] prompt.

This appears to work around a bug in BRE, FE, and TAL where they don't
recognize the "1" (ANSI supported) unless there is at least one other
character on the line following the decimal digit, resulting in the
unnecessary prompting of the user:
  This game is much more enjoyable with ANSI graphics enabled.
  Do you want ANSI Graphics? (Y/n)

As reported by "ben" in IRC.

When used, replaces built-in user (e.g. terminal) settings menu with a
loadable (e.g. JS) module.

This should avoid/work-around issue #630

Nelgin's terminal server log indicated that the node's configuration was being
reloaded for a new client connection (which doesn't normally/always happen,
only when there's been a config file change or a node "rerun" requested),
while there was still a user online using that node. This would explain the
segfault (configuration fields being freed and reallocated).

The node_socket[] array indicates when a node thread is actively servicing
a client, so it should contain INVALID_SOCKET for the any node's that WFC.
If it doesn't, that means something/someone changed the node's status value
to 0 (WFC) in the node.dab file while the node was still in-use. Let's not
crash in this case and rather just log the message and give the client the
next available node (if any).

Some of the errors could be pretty vague since they looked the same and
we were depending on the path/file attempted to be opened in the log msg
to clue us into what exactly was being attempted. But some of these file
paths are sysop-configurable, and they can put unexpected things in there
that make it difficult to determine exactly what file was trying to be
opened and for what purpose. This should help a little bit.

This allows the calling script to control what the default item is (when the
user just hits enter), and not always the first item.

Fixes issue #637

tbz is technically still supported by create_archive(), but without it
being included in the supported_archive_formats definition, isn't easily
chosen as an option and nobody seems to miss it.

Apparently one was copied from the other and used the same original
output file subdirectory name ("upgrade") oops.

I didn't notice that these projects were still being built with a toolset
that didn't target WinXP. I might need to update the SDK too.

Also, although not a bug (because we re-read/parse the user's record every
menu cycle), don't decrement user.xedit before calling uselect()
- just not a good practice to not modify variables unnecessarily.
See the corresponding change to exec.cpp, which was a bug.

This bug would leave the user's external editor setting decremented by one if
they aborted (with Ctrl-C).

Fixes issue #631

Most logs sysops are looking at already have a date/timestamp for each
message, so this one ended up with 3 date/timestamps in a single line.

This fixes issue #629

I'll add detailed docs to http://wiki.synchro.net/custom:atcodes soon, but the
list is:

- TERMTYPE
- TERMROWS
- TERMCOLS
- AUTOTERM
- ANSI
- ASCII
- COLOR
- ICE
- RIP
- PETSCII
- SWAPDEL
- UTF8
- MOUSE
- UPAUSE
- SPIN
- PAUSESPIN
- EXPERT
- HOTKEYS
- MSGCLS
- REMSUBS
- FILEDESC
- FILEFLAG
- AUTOHANG
- AUTOLOGON
- QUIET
- ASKNSCAN
- ASKSSCAN
- ANFSCAN
- EDITOR
- SHELL

This should (at least mostly) address the issue #629

Apparently if you call mosquitto_publish_v5() with a non-NULL properties
pointer, it'll only publish via protocol v5 and doesn't work if you're using
protocol v3 connection.

Thanks Ree.

... regardless of the configured MQTT protocol version (v5 or v3.x).

Also include an MQTT v5 user-property ("time") with the message's origination
time/date stamp in ISO-8601 format in all log messages (to both topics).

This will at least double the amount of MQTT log traffic to the broker. When
MQTT v5 is used, the additional user-properties will increase it even a little
more.

Is this what you were suggesting Ree?

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

This should fix issue #626

The node message should be terminated with a newline character.

e.g.
$ echo "Hey you" | mosquitto_pub -s -t sbbs/VERT/node/1/msg

I'm considering the ability to send user message (telegrams) via MQTT too.

Just make the list argument a void* and assign to a void** local
var inside the function. No functional changes.

Fixes issue #621

To be more consistent with the paste key behavior elsewhere in SCFG,
make the file options (Viewable Files, Testable Files, Download Events,
Extractable Files, Compressible Files, and Transfer Protocols) menus handle
paste (Ctrl-V, F6) key by inserting the copied or cut item above the current
selection rather than overwriting the current selection.

Fixes issue #616

Fixes issue #611

<nelgin> Remind me why you can't show the ip address on node status? :)

Using the new '-v[key]' option, a sysop can view one, some, or all of the
key/value pairs from the nodes with a connected client. For nodes without
a connected client, the client.ini file values aren't particularly useful, but
if someone wants an option to show those values for non-client-connected nodes
I can do that too.

When using '-v', all the client.ini key/value pairs will be displayed for all
the node records requested with currently connected clients. By specifying
'-v[key]' the sysop can specify a key to display (rather than all of them)
e.g. 'node list -vaddr' to list nodes with remote client IP addresses.
This option can be used multiple times on the command-line to view multiple
keys. See node*/client.ini for the list of supported keys.

This feature only works for nodes whose directory paths are ../node#/
relative to the ctrl directory. Since the node utility doesn't read any
configuration files, this is a limitation. If you have different node
directory names/parents and need to use this feature, let me know and I'll
see about adding support for reading/parsing main.ini file to discover those
non-standard/default node directory paths automatically.

The version number displayed is now taken from the sbbs version (sbbsdefs.h).
The maximum ctrl directory path is now extended from 40 chars to MAX_PATH.
More readable help/usage output (using indentation).

A follow-up to commit 81d4575e

Although I was not able to successfully reproduce the problem that Ree
reported with his commit (even when changing the SCFG->Networks->MQTT->Publish
QOS to 1: At least once) on Windows, I do see how this problem could
theoretically happen. And like Ree said in the follow-up comment on the MR
"maybe these two lines should have stayed in mqtt_startup", they don't really
belong in the connection callback.

The "client" topics only needs to be cleared upon startup or recycle (by
publishing a null message) and it would be bad to clear these topics whenever
the broker was reconnected (the server's clients didn't magically disconnect).
So these "client" topic-clearing publishes are now only done during startup
(again).

The "recycle" topics don't really need to be published to here at all. I
think I only did this for cases where someone published a non-null message to
the topic and its stale message would remain afterward, appearing in MQTT
browsers (like MQTT explorer) long after the server had recycled. The real
solution to this cosmetic issue is to only publish null (0-length) messages to
the "recycle" topics in the first place.

Wasn't opening the sbbs.ini file for modify access.

As reported via DOVE-Net by Accession (PHARCYDE)

This appears to just be a miss from the initial commit (bd97c9d8) of the
directory default configuration (per lib) feature, so a file
lib's directory default "data dir" wouldn't be read from file.ini.

This fixes issue #602 reported by Nelgin.