Fixes CID 351271

Might add some other statistic for these relayed posts at some point.

Hunting down and destroying some super old SBBS code now. :-)

Defines the field indexes for records in csts.ini

Generates a "Dd Hh Mm" string from a specified number of minutes.

I was stripping the path here... oops.

*/dsts.dab was replaced by dsts.ini.
*/dsts.ini is just a text file, you don't need a special editor.

*/dsts.dab (daily statistics and running totals) -> */dsts.ini
*/csts.dab (cumulative statistics / log) -> */csts.tab

* dsts.ini now has both daily and total stats for all fields (not just timeon and logons).
* dsts.ini is now an easily modifiable text file - no longer need dstsedit (here-by deprecated and soon to be deleted)
* dsts.ini and csts.tab support 64-bit upload/download byte stats and are very extensible for future fields to be added or extended > 32-bit (this was the main inspiration for this overhaul, but it was overdue and already designed for v4, pretty much)
* csts.tab is a tab-delimited fixed length record format suitable for easy import to a spreadsheet program or parsing with scripts. Each day is a 128-character LF-delimited record with tab-delimited fields of plain ASCII text.
* All fields except timeon in dsts.ini files are updated immediately and by more non-terminal servers (e.g. post statistics from web UI scripts).
* New user stats are tracked more than just for "today".

The upgrade of these files is automatic and built-into SBBS.

Still to do: overhaul the slog utility to support the new csts.tab file format.

Windows doesn't allow multiple directories of the same name only differing in case, so don't on *nix either.

Fix the fix to issue #380.

Thanks for letting me know Keyop.

Fixes crash reported in #381.

And data/dirs/*.msg display file. Now you can have any supported menu file in this location if you wish.

I'm so tired of this 30 year old frequently asked question.

If a sysop really wants their Synchronet BBS to only work correctly for ANSI users, I suppose that should be their prerogative.

I always felt that by not detecting/displaying menu files when the minimum set of files was not present, I was helping sysops to identify an issue with their system (which would not work correctly for non-ANSI users). *And* I always felt that having a single menu/display file that correctly supported both ANSI and non-ANSI users was a nice convenience (who really wants to maintain multiple versions of their menu files?). But I'm so tired of answering this question, I just give up.

Hopefully this doesn't break anything for anyone. <shrug>

That previous commit made all *.40col.msg files display for 80 column users. Not my intention.

So revert to the previous behavior of *.XXcol.* display files. I didn't want to go renaming a bunch of menu files as a result of the previous commit and I didn't want a bunch of sysops with *.XXcol.* files to be suddenly surprised at their new BBS behavior.

And introduce a new file naming convention, *.cXX.* (where XX is a MINIMUM column width). This is the same naming convention used by Mystic, which also treats it is as a minimum terminal width, not a required exact width.

e.g. display basename.132col.msg even if the terminal is 133+ columns wide.

Fixes issue #380.

glob() is case-insensitive on Windows already, so create a work-alike for *nix.

Fix for one of the problems described in issue #380.

bbs.menu("random*"); would display column-width-specific files (e.g.
random.132col.msg) even when they weren't appropriate for the current
user terminal width.

This is fixed by truncating the filenames matching the requested pattern at
their first-dot rather than the last.

The downside is, you can't have a set of random.#.* files, where # is the
unique part of the filename and * is the file-type extension. Just use
the naming pattern "random-#.*" instead (or something similar) instead.

Fixes recently broken Win32 build

I knew I created these is_valid_*num() functions for a reason!

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

We don't have a use case negative byte values in strings anywhere that I can think of.

Created wrapper for MSFT _ui64toa_() - unsigned 64-bit integer to ASCII string.

Add Petabyte (actually, Pebibyte) support to byte_count_to_str()  and byte_estimate_to_str().

Removed 'B' suffix from byte_estimate_to_str() output for values < 1024. Callers may display this returned string followed by "bytes" (or similar) and thus the 'B' suffix is redundant in that case. If the caller needs a 'B' suffix, they can detect no suffix and add it.

warning: invalid suffix on literal; C++11 requires a space between literal and string macro

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.

comparison of integer expressions of different signedness: ‘off_t’ {aka ‘long int’} and ‘uint64_t’ {aka ‘long unsigned int’}

Used the reserved 16-bits in the file index record to extend the supported index-file-size from 4294967295 (4GB) to 281474976710655 (281TB). I think that's big enough for the foreseeable future. :-)

Size is indexed, so might as well sort by it. This does have an issue with files >= 4GB in length however, so I'm looking at that next.

Query the disk for file's current "size" and "time" values when get_list() or get() method is used with a "detail" level of >= DETAIL.NORMAL and the "check file existence" toggle option is enabled for this directory in SCFG.

I pondered and contemplated whether this configuration setting should be checked/applied here or in the various JS scripts (e.g. filelist.js) and decided here was best to provide the most uniform/expected behavior, even though there is a performance impact. If a script doesn't need/use these properties, they should probably be specifying the DETAIL.MIN (minimal) detail level in their queries anyway, which will then bypass these performance-impacting disk queries.