A copy/paste from websrvr.c

This needed a custom solution (not errprintf) since the filename is passed-in
is likely from dynamically allocated memory, so a pointer comparison isn't
enough - and we don't get the function name.

This is a solution for issue #842, but only for messages posted/sent from the
terminal server using built-in functions and not via JS or other means. A more
universal/generic solution would be nice (beyond just always storing message
headers and bodies in UTF-8), but nothing has come to mind.

part of fix for issue #619

Part of solution for issue #619 (for the web server)

Part of solution for issue #619 (for the mail server)

For alignment with the text() method and for instances where a script author
doesn't want to load('text.js') or use [bbs|system].text.ID to get a text.dat
string index from an ID.

(which might be UTF-8 encoded). This works-around the problem that Accession
reported in #synchronet with my reply to a UTF-8 encoded message using a CP437
terminal which resulted in a message body that was UTF-8 encoded but a message
subject that was CP437 encoded. This mix of encodings is not supported by FTN
standards.

This is just a work-around since if the user modifies the subject the result
could still have the CP437 unside-down question marks (indicating
non-translatable UNICODE chars) and those should be converted to UTF-8
chars when going out on FTN or being stored in the message base. So there's
still a bug here somewhere that I need to look into more.

- when converting from CP437 to UTF-8
- when reading from RESULT.ED drop file

This effectively limited message subjects in some instances to 69 chars
instead of 70. This bug was caught while debugging a replied-message subject
conversion from UTF-8 to CP437 issue reported by Accession.

Since we we're not using opennodeext(), we don't have the path/fname for
any failure error message here.

CID 515714

This would cause the "Logout" status and multinode chat activity
strings to be truncated to 3 or 7 chars.

CID 515713 and 515715

Use strlcpy instead of strncpy

Custom NodeStatus and NodeAction/Activity strings are now displayed pretty
much everywhere possible (except the node utility, since it doesn't read
any configuration files). This fixes issue #618, finally.

If you have custom (non-blank) NodeAction* strings in your text.dat/text.ini
file, or you change these strings during runtime (e.g. using bbs.replace_text)
this will impact you:
- do not include the user name or any other fields normally included in
  printed node status in your string - just the customized node action and
  really, you should only use/override these strings for dynamically changing
  node status (i.e. you're using NodeActionCustom and you're setting different
  custom strings depending on current node activity). Consider using the new
  NodeActivity* text.dat strings instead if your customized string doesn't
  change during run-time.
- don't use the %s/%u/%d specifiers any more - use @-codes instead, if needed

If you want static/permanent node action strings, set new new NodeActivity*
strings in your text.dat or (preferrbaly) text.ini file instead.
This means the node actions can now be localized for other languagues!

I'm still using the node.exb file (I did consider alternatives, e.g.
node.ini or node*/activity.asc), but decided to postpone such a change.
The node.exb file is still used, but the strings represent just the custom
(extended) node *activity* and not the entire node status string.

Use of Ctrl-A codes needs to be considered/accounted-for (currently isn't).

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.