The newly created/used link_aera() function was copying the address of the
passed fidoaddr_t pointer rather than the value (fidoaddr) pointed to.
This is the actual fix for the problem reported by Tom Moore (1:135/205)
- tested and validated. It only immediately impacted areas.bbs use
(not areas.ini), since we wrote a stringified address directly to the
areas.ini file "links" key. This was not an allocation issue but a memcpy()
issue.

Other unrelated changes:
- Log a debug-level message when ignoring a "NO-ECHO" message (subject "NE:*")
- Log a notice-level message when ignoring a message due to GATEWAY VIOLATION
  (gating a message between net-types when not explicitly configured to do so)

So, (sizeof *addr) now looks right got me (this should've been the same as
sizeof(fidoaddr_t)), so the change in commit e2476ebb doesn't actually look
like a fix, but maybee a regression.

I need to test some area manager link additions and get to the bottom of this,
but this particular change was not a fix (and caught/reported by Coverity -
CID 515673).

This is likely the cause of the areamgr issue that resulted in weird/invalid
node address being added to the area file, reported by Tom Moore (1:135/205).

There still appears to be some race condition with network (Samba) FS
directory caching and opening/locking of files, so it does seem illogical that
the packet file wouldn't exist at this point (since we have the lock file
opened) but this does still happen on occasion on Vertrauen.

A negative timeout value doesn't make sense and this will extend the legal
(positive) range of this parameter value.

Hopefully this will help eliminate these errors I get often:
  dd_lightbar_menu.js line 4041: Error: can't convert inputTimeoutMS to an
  integer

But if there's some way that this parameter value is even out of the range of
an unsigned 32-bit value (4294967295) then this error could still happen.
Unfortunately, the JS exception doesn't report the value that failed to
convert.

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

Need to unlock the mutex before calling errormsg().

Need unlock the mutex in error path of unlocknodedat().

I'm not clear why this would, but it might resolve CID 515601 which looks
like false positive to me: getnmsg()->putnodedat() should never leave
nodefile_mutex locked.

Resolves CID 515657

I don't think this was actually a leak (since smb.msgs should be non-zero
any time mail is non-null), but to make Coverity happy (CID 515659) and just
be more fault-tolerant, always free(mail).

(128 bytes)

Fix up the filename in error messages reported during unpacking QWK packets
(MESSAGES.DAT not BBSID.QWK).

Convert more log messages to use de-duplication as solution to issue #619.

A lot more lprintf() -> errprintf() conversions will be needed to fully
realize this solution (e.g. in the mail, ftp, web, services serverss).

In printfile() and printtail() which are used by menu() and many other
functions.

These should be helpful to sysops that just want to know what file is being
displayed under what conditions (e.g. for trouble-shooting or customization
reasons).

... instead of just the file name, as was expected.

Under heavy loads, I've found periodic non-blocking lock attempts just aren't
reliable enough: in particular, on Vertrauen, the guest user account record
in the user.tab file gets read and written-to A LOT (updating stats), and
under heavy loads (especially with hundreds of web client sessions), I'd get
timeouts attempting to lock the guest record in the user.tab (after about a
minute of periodic retries) - so let's just block "forever" to get the user
record lock (or until signaled or notified of a deadlock). With this change,
I've not had any user.tab lock errors or apparent deadlocks.

Let the underlying OS/filesystem handle queuing and deadlock detection,
when supported. lock() still behaves as before: non-blocking lock attempt.

... from ERROR to WARNING, so the repeats won't be logged to error.log file
and won't (normally) be sent as notifications (e.g. emails) to the sysop. The
duplicates are identified as from the same source file and line number as the
immediately previous logged error within the last 12 hours. String comparison
doesn't really work for deduplication since if you look closely, the errors
usually are *not* exact duplicates (i.e. there's a node number or a socket
descriptor or something that uniquely identifies the user/client/session).
Repeated errors don't increment the node's error counter either.

This does not de-duplicate errors logged via other means (e.g. direct calls to
log()/lputs(),lprintf() with a severity of LOG_ERR or higher), but will
solve the majority of duplicate errors that can be logged from the terminal
server.

So this at least partially addresses issue #619.

Even though we use O_EXCL, networked file systems still sometimes allow the
secondary open() to succeed. We use record locking in xpdev's sopen()
implementation for *nix, so this lock will insure such opens (and locks) will
now fail.

This is an attempt to address occassional error on Vertrauen:
ERROR 2 (No such file or directory) renaming *.rep to *.bad

Return correct error value upon seek failure.

"performing custom action"

Normally, the sysop would set the NodeActionCustom text.dat string
to override this.

This is to be used (e.g. instead of NODE_BXFR) for sysop-custom node actions.

so that if multiple entities call these functions at the same time, they
don't retry at exactly the same times.

Add/use SOCKET_STRERROR which gets the description of the *last* socket
error.

We should start using socket_errno(true) in place of ERROR_VALUE (horribly
named macro) for comparing last socket error nubers against values/macros
from errno.h.

Eliminate get_socket_errno(), unused and redundant with socket_errno().

Addresses Clang warnings about deprecation

These functions now return a common set of non-zero error values (where
appropriate), defined in userdat.h

Don't return errno.

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.

It's possible now for clients to easily exceed the configured max concurrent
connections limit, even though they just get an error 429 page. Let's at least
track and log when a new highwater mark is reached.

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

We can't send a 4xx error (ie: client did something wrong) in
plaintext on a TLS connection.

Untested beyond a basic compile check.