Credits and daily free credits are accurate to the byte up to (a maximum) of 18446744073709551615 (that's 18 Exbibytes - 1).

User's upload and download byte stats are now similarly extended in maximum range, but the accuracy is only "to the byte" for values less than 10,000,000,000. Beyond that value, the accuracy declines, but is generally pretty damn accurate (to 4 decimal places beyond the nearest multiple of a power of 1024), so I don't expect that to be an issue. This method of storing upload/download byte stats allowed me to use the same 10-character user record fields in the user.dat file.

As a side-effect of this enhancements:
* User and file credit values are now expressed in multiples of powers of 1024 (e.g. 4.0G rather than 4,294,967,296).
* Free credits per day per security level has now been extended from 32 to 64-bits (to accommodate values >= 4GB).
* adjustuserrec() now longer takes the record length since we can easily determine that automatically and don't need more "sources of truth" that can be out-of-sync (e.g. the U_CDT field length going from 10 to 20 chars with this change).
* setting the stage for locale-dependent thousands-separators (e.g. space instead of comma) - currently still hard-coded to comma
* more/better support for files > 4GB in size (e.g. in the batch download queue)
* user_t ulong fields changed to either uint32_t or uint64_t - I didn't realize how many long/ulong's remained in the code (which are sometmies 32-bit, sometimes 64-bit) - ugh
* Steve's ultoac() function renamed to u32toac() and created a C++ wrapper that still uses the old name, for homage

To fully support files > 4GB in size in file bases, credit values larger than 32-bits must be supported too.

There's a couple of todo comments/items included in this commit, but that's mainly to do with messages (which don't really have costs anyway).

The main thing to deal with now is the fact that users can't have more than 4GB in credits in the first place! That's got to be fixed next.

CID 330961

Testable File Types and Download Events support working strings (display before/while the command-line executes). Clear the current line (displaying this working string) when the execution completes.

This fixes issue #328.

The user actually *can* remove files from the batch queues in v3.19b, but you have to type the filenames which is not obvious from the prompt which implies you need to type the file index position (e.g. '1' for the first file in the queue). In all Synchronet versions prior, you could only remove by number (and not by name).

The fix is to allow either the number or the name of the file to be entered at the RemoveWhich prompt and the file is removed from the queue successfully.

Thanks Ragnarok!

Default the progress time interval to 500 milliseconds (twice a second).

Don't specify a count/call interval in the call-sites, since we really want to use time-based progress updates now only and the default probably will work fine everywhere.

The internal line editor's quoting feature add some hard-coded strings ("Done" and "All") and the (L)ist key was hard-coded. Use the text.dat string (new and pre-existing) for these now.

Also, use the new sbbs_t *_key() methods for referencing the configured key bindings (via text.dat) for these common key-stroke commands.
Convert the text.dat strings for keys (e.g. YNQP) to uppercase always as well.

When there's no "uploads" directory configured by the sysop, cfg.upload_dir will be set to INVALID_DIR, which cannot be used as an index into cfg.dir[] to determine if the time used for uploading the files should be "given back" to the user.

In v3.18, we used the first file in the upload queue, if there was one, else fell back to the "uploads" dir (which had to have been defined if there were no files in the queue). So this illegal array indexing was a regression in v3.19.

Reported by Zoltán Gábor on Facebook

Not that it really matters, but perhaps it'll matter in the future. And the code reads better.

The BadFilename text.dat is now a format string (prints the bad filename).
Use the nice progress() display status while searching for duplicate filenames.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

- Move files from temp directory to uploads directory *before* determining what the short filename is going to be (since the underlying file system can change the short filename during that process). This should resovle the issue of blind-uploading multiple files with long filenames that begin with the same prefix of 6-8 characters.
- Batch upload queue processing wasn't touched as part of this change. That logic probably also could use a similar fix.

this code is on the chopping block already.

conditions) - e.g. if a malloc or realloc failed, then some other allocated
memory would be leaked.

If a filename had no extension, it could not be added via batch download
list since this code was truncating all white-space off each line read.
Now it will just truncate end-of-line characters.

was never used. This was intended to be a method for internationalization,
letting the sysop change which key is used as the uiniversal "quit" key.
This commit replaces most of the uses of the hard-coded 'Q' for quit wtih the
3rd charcter in the text.dat YNQP string. Some hard-coded menus still have the
'Q' key hard-coded and will need to be addressed later. The text.h YN index
macro was changed to YNQP and the JS text index variable name will change
as well.

That is, if any of the following text.dat entries are set to a blank/emtpy
string (by editing ctrl/text.dat or via run-time script modification), the
question will not be asked of the user allowing greater sysop-customization
of hard-coded processes (e.g. new user application):
ClearUploadQueueQ
ClearDownloadQueueQ
HangUpAfterXferQ
ChatWithGuruInsteadQ
ForwardMailQ
DownloadBatchQ
LogOffQ
DeleteErrorLogQ
ClearErrCounter
DeleteGuruLogQ
AutoTerminalQ
AnsiTerminalQ
ColorTerminalQ
ExAsciiTerminalQ
CallingFromNorthAmericaQ
ReadYourMailNowQ
NScanAllGrpsQ
SScanAllGrpsQ
NewPasswordQ
ContinueQ
EnterYourPhoneNumber
UserInfoCorrectQ
UseExternalEditorQ
DownloadAttachedFileQ
AddSubToNewScanQ (new)
RemoveFromNewScanQ
DisplaySubjectsOnlyQ
Post
SearchExtendedQ
ViewSysInfoFileQ
ViewLogonMsgQ
WithLineNumbersQ

Added HOST and IP keywords to allow restricted access/privileges to/for
specific remote hostnames or IP addresses (wildcards allowed).
All string-argument type ARS keywords (e.g. SHELL, PROT, etc.) now support .can
style wildcards.
The current remote client is now used for protocol, host, and IP ARS checking,
when available, so this requires passing the client pointer around (which
explains why so many files are touched by this change) and takes care of a
long standing to-do item (the user's 'modem' value was used for the PROT
value checking, which was not always correct).

(e.g. with SEXYZ or RZ), then it would not be properly added to the database
(but the file would be copied to the destination directory).

the file transfer protocol is "Native 32-bit" (e.g. Nemesis Transfer Protocol).

etc).

if text/menu/*prot.asc does not exist.

can make a download free for a particular user from a particular file area,
with support for per-directory exemption ARS (finally).

file databases.

empty, now returns BOOL instead of VOID.

variants (gmtime_r, localtime_r, and ctime_r) for thread-safe operation on Unix