When writing the attached file path/names to the FLO file, parse each
filename out of the subject, accordingly. This should fix issue #824.

There's an inconsistent support in SBBSecho for FileLists in the subjects of
netmail messages. In a couple of places, single-space-separated filelists are
fine (but not commas or multiple space, even though they are allowed per
FTS-1).

This particular fix is just for the packing of netmail messages and the
appending the attached file(s) to the FLO file. Those other places (e.g.
.REQ file creation) will need their own fixes for proper filelist support.

... to be sure configured newsgroup name is RFC compliant.

also retrying fread() and chsize(), but that seems harmless.

Note: EBUSY was added to the list of errno values that should cause a retry
as observed on Vertrauen, running sbbs-linux on a Samba mount, opening
locked files can return failure (-1) with errno = EBUSY, e.g.
evnt BBS Events !ERROR 16 (Device or resource busy) in logon.cpp line 616 (logonstats) reading "system stats" access=0

This was apparently resolved by adding EBUSY (16) the values that trigger an sopen()
retry (i.e. from [f]nopen()).

Remove the grease.

This is a suitable amount of paranoia now.

Should fix log-padding infinite loop.

I suppose if we only had messages with no body text, this value could be 0
(not accounting for any headers) and thus throw a client off.

So consider this as part of the fix for issue #822.

For messages that have no body, we'd report 0. But RFC 1939 says this value
is supposed to be "the exact size of the message in octets" <sigh>. This
would include header fields, so while we can't know the exact RFC822 size,
adding the msg's hdr.length to these values gives size > 0 for messages
with no body text and this enables the Apple iPhone Mail app to download
the message (fixing issue #822).

Part two of this fix is to provide a blank line of message text when there
is none. This changes the message displayed in the iPhone Mail app from:

"This message cannot be displayed because of the way it is formatted.
 Ask the sender to send it again using a different format or email program.

 text/plain"

to (the much nicer):
 "This message has no content".

Change the message.

For some reason, I thought socket.send() did this, but apparently
not.  Fixes issue transferring large messages.

Also, add support for the useless NAMESPACE command.

The sets of message bases you want to get over different protocols
may be different.

While we're here, fix an error with single-parameter FETCH parsing
which prevented Sylpheed from being able to read messages.

Instead of text with completely different meaning, change the "no body"
text to a single space.

Rather than locking for just one message, lock for the entire command
when potentially updating Seen data.  With this, we can block all
connections the user has except the currently executing one, and
not need to read/write the seen data between every message.

While this can take minutes on very large subs, it's certainly
better than hours as previously.

It's rude to have multiple sockets actively pumelling the server
anyway.

This speeds things up a fair bit, and will make things faster after
an initial scan.  I may expand this method a bit to lock other sockets
for for either some period of time or some number of messages to
allow the initial scan to be even faster.

Previously, this uses INI format files, with ini file accessors
to read and save this file.  Now it just dumps a JSON file in and
slurps it out.

This saves about 0.4s/msg on my system when reading headers.

If the INI file could not be opened, a failure would be returned,
but authentication would (potentially) succeed.  I can't think of
a way to exploit this, but it's getting late.

Also, make some minor optimizations that won't make a difference yet,
and move opening the file into a single function.

With the incremental backoffs, these were super long waits for locks. Not sure
about my math there, but at 500, the total timeout was not "about 45 seconds"
but rather several minutes.

At 100, the total max retry time should be almost exactly 45 seconds:

Retries      ms-per     total seconds
  0 - 9      0          0
 10 - 19     100        1
 20 - 29     200        3
 30 - 39     300        6
 40 - 49     400        10
 50 - 59     500        15
 60 - 69     600        21
 70 - 79     700        28
 80 - 89     800        36
 90 - 99     900        45*
100 - 109    1000       55
110 - 119    1100       66
120 - 129    1200       78
130 - 139    1300       91
140 - 149    1400       105
150 - 159    1500       120
160 - 169    1600       136
170 - 179    1700       153
180 - 189    1800       171
190 - 200    1900       200!

... so yeah, 500 was way too big a number.

And only supports a single file per invocation now.

It makes a difference on *nix.

So this change is needed or else fcntl() will fail with errno=BADF if trying
to write-lock a file that was opened read-only. Oh well. Added a comment
explaining the rationale.

OFD locks are needed on Linux for appropriate multi-threaded shared file
access (using fcntl record locks to prevent corruption), so log a warning if
building for Linux without that support.

lock() now mimics DOS/Windows again: the result lock is an "all access" lock
regardless of what mode the file was open in. I'm not sure why this change was
made (commit 11b73134), but I don't think it was necessary or
appropriate (though I can't think of any immediate negative effects). At
minimum it makes the code a little more understandable and eliminates an
extra call to fcntl().

This is the program I used (along with flock) to reach the root cause of
the SH_COMPAT == SH_DENYRW (no locking) bug in sopen() as well as other
interactions between Linux and Windows clients opening the same files
across a Samba share.

You can't lock a file on a Samba share via both fcntl() and flock() (the
interact/collide).

This code was in a !BSD block which means they guy that wrote/committed
it wasn't using it either.

SH_DENYRW (deny-all) locks were broken 18 years ago with commit b866f199.

This fixes that by treating SH_COMPAT the same as SH_DENYNO (only), rather
than the same as SH_DENYNO or SH_DENYRW (and performing no locking).

This is likely the/a root-cause of some SBBS file corruption on *nix systems.

It appears Deuce's FreeBSD patch isn't going to be accepted/merged
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=50827), so I'm
making this code a little more readable/manageable by removing this
unused feature... for now, with Deuce's approval.

This solves issue #817 for TLDR messages imported into DOVE-Net Tech Talk,
because those messages are imported via SMTP originally and thus have the
original (MIME/Q-encoded subject) in the message header (as RFC822SUBJECT).

For other messages with UTF-8 characters in their header fields (e.g. subject),
we'll need a different solution (Q-encode header fields that contain
non-ASCII chars on the fly), and then this solution could maybe be reverted.

GCC and Coverity (x 2) both flagged this one.

Properly read the index of the base, not of the base_code.
Fixes badly broken STATUS command.

Also, change the default smb_t.retry_delay from 250 to 100ms

Getting a lot of smb_locksmbhdr() failures with sbbs-Linux accessing message
bases (i.e. SYNCPROG in particular) on Samba share.

Similar to what I do with user.tab record locks 2 months ago, this will
extend the total shared/network file open attempt duration from about 5
seconds to about 45 seconds, but with incrementing back-off.

Trying to sbbs-Linux to run from a Samba share without file open/locking
errors.

Re-synced the sbbs_t version of nopen with the nopen.c version (wasn't
special-handling EDEADLOCK failures).

Mostly we're using fnopen() these days anyway, which doesn't have an sbbs_t
version (for logging warning messages about collisions), perhaps it should.