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.

- sbbs/BBSID/exec (publish the timed event's internal code)
- sbbs/BBSID/call (publish the QWKnet hub's ID)

The message contents are not case-sensitive.

e.g. publishing "0" to node/#/set/intr will clear the node-interrupt flag.
Any non-zero message value will "set" the flag. Same is true for the
lock, down, and rerun topics/flags.

These node attributes (misc) flags could be cleared previously
by setting the 'misc' topic (e.g. to 0), but since that's not an atomic
read/modify/write operation, other set misc flags could be lost clearing flags
in that manner.

<nelgin> can I push an intr instruction to a node with mqtt?

node/#/set/status - set the node status value (to an integer)
node/#/set/errors - set the node error counter (to an integer, e.g. "0")
node/#/set/misc - set the node's miscellaneous attributes/flags value
 (hexadecimal values can be set by including "0x" prefix)

The message (payload) doesn't matter for the following topics:
node/#/set/lock - lock a node (no one but sysop can login)
node/#/set/intr - interrupt a node (disconnect a user)
node/#/set/down - down a node (not available for connections)
node/#/set/rerun - rerun a node (reload config upon next connection)

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

A "prepped" means directory means a relative path from the configuration files
(or default settings) has been converted to a full/absolute path with proper
slashes for the platform (i.e. backslashes instead of forward-slashes on
Windows).

JSexec doesn't require that the new v3.20 ctrl/*.ini files exist to run; this
was necessary to be able to run 'jsexec update -> upgrade_to_v320.js' which
does the ctrl/*.cnf to .ini file conversion (egg not required to build
chicken). When JSexec failed to load ctrl/msgs.ini
(e.g. "!ERROR loading configuration files: 2 (No such file or directory)
opening /sbbs/ctrl\msgs.ini"), it would continue to run, but not "prep" any
of the "path" settings (e.g. exec_dir).

The first run of 'jsexec update.js' would fail to run upgrade_to_v320.exe
(which does the v3.20 user base conversion) and a bunch of other (but not as
important) update steps because Windows couldn't execute "../exec/*".

Multiple errors would be displayed in this case, but the most important (as
reported by Ree in #synchronet of irc.synchro.net) was:
  '..' is not recognized as an internal or external command

right after the status output:
  No v3.20 user base found, running ../exec/upgrade_to_v320

Notice the "../exec/" prefix, which is not support by Windows when specifying
a file path to execute.

A second run of 'jsexec update' would work fine because the new v3.20 .ini
files would be successfully created after the first run (though the user base
was not).

This is likely the same issue that MRO reported recently when upgrading a
Windows SBBS v3.19 install to v3.20 and not having the user base upgraded
the first time.

As reported by Deon on DOVE-net, when the call to socket_recvdone() returns
true (socket is disconnected and all data has been recv()ed), dial() would
report "NO CARRIER" but leave the open socket opened, thus preventing any
subsequent dial attempt ("Can't dial: Already connected" and "ERROR").

Also removed the source file path/name from the debug print statements - don't
need that noise.

Incremented the version to 0.4

This allows directly setting bright foreground and background colours
rather than using bold and blink to indirectly modify them.

These do not have an effect if the desired mode is not possible
(ie: no bright background, no bright foreground).

Fixes SF issue 118

For example, if it was set to 0.4, the initial scaling would be set
to take at most 40% of the screen height or width (whichever is
smaller) with a minimum of 1.0

There's a few ASCII control codes that need to be translated, so
add a new mapping function that tries the map first, then returns
ASCII on failure to map.

Fixes inability to use ATASCII in curses mode.

Previously, both the shift key, and the "implied shift" from CAPS
were treated as a higher priority than the CTRL modifier.  With
this change, only the explicit shift key has priority, and the
implicit one is only checked after CTRL is checked.

Fixes SourceForge bug 117

I keep reverting/un-reverting the merge that includes an unrelated logon.cpp
change. So just manually remove this new code that was added to attempt to
fix issue #402 since I incorrectly concluded that sockopts.ini wasn't being
applied to new sockets created with ListeningSocket().

This reverts commit 110326c7.

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

This reverts commit 5f1ab933.

Wrong commit reverted. Oops.

This reverts commit ce1946fa.

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.

This socket constructor did not get the global socket options treatment when
created (years ago).

This should fix issue #402 as reported by Nelgin and more recently by Keyop.

If the search up the scope tree for js.exec_dir fails, the script 'path' would
be left blank leading to a weird error message.
e.g. !JavaScript default.js line 249: Error: Script file () does not exist

When there are no changes (areas added or removed) via an areafix message, the
data/AREASxxxxxx temp file would be left behind. The file was only removed if
areas were added or removed from the area file via areafix message.

The orphaned data/AREASxxxxxxx files were reported via DOVE-Net by Gamgee (PALANTIR)
If you have these stale files, you can safely delete them.

As reported by Pasta68K:
FreeBSD's ln doesn't support -r

ln -sfr clang.freebsd..exe.release/* /sbbs/exec
ln: illegal option -- r

So use realpath instead. Hopefully all the targeted *nix platforms include
'realpath'.

Make behavior consistent with smbutil and fixmsb.

Eliminates a SANITIZE build error

I don't believe them, but I'll fix it anyway.