The old query was:
* Selecting data from 2 months ago instead of 1 month ago for some reason, presumably left over from when I was testing the query out for different time periods.
* Counting non-new players who used a new download source as new players.
* Add ability to allow secondary authors to upload an add-on.
The secondary_authors attribute is a comma-delimited list of forum accounts that can also upload updates to an add-on. Secondary authors can't change the primary/secondary authors and can't delete the add-on.
The primary author can also make someone else the primary author by:
* Putting their username in the secondary_authors attribute
* Putting someone else's username in the author attribute
* Uploading the add-on while selecting themselves
This works since they are still (until the upload is done) the primary author in the database, so they are allowed to change the authors list, including in this case.
Required for the updated primary key - the max allowed primary key length is 3072 bytes which isn't enough when there are three VARCHAR(255) columns and each character uses 4 bytes. The max length of the data in these columns so far is also well under 100 characters.
The cause is that somehow, during regular play, MP campaigns can end up with duplicate values in the [content] data for each [addon]. A very similar issue was fixed in 6c980d12dc, but there's apparently some other way to trigger it that I haven't been able to reproduce. Since the error itself is harmless, it'll just be avoided server-side to avoid the spurious errors in the server log file.
The idea being that this could then also be included as a sheet in the multiplayer activity report, which would then be an easy way to view add-on downloads over time. This would of course not be especially useful until 1.18, since for 1.17 the database count would be starting at 0 even though existing add-ons would have a non-zero download count.
Reasoning being:
* The result_set and other APIs are nicer to use.
* We use mariadb on our server rather than mysql, so this would minimize the chance of any incompatibilities.
* The mysql C++ connector 1.1 isn't compatible with with c++17 (https://stackoverflow.com/q/47284705).
* Whether the game allows observers.
* Whether the game's replay should be publicly available (currently the same as whether observers are allowed pending the second part of #3909).
* Whether the game had a password set.
* The side's name - this differs from what can be retrieved from USER_ID since it will have the name of any AI used.
Add a "BSD Repository" option.
Add data/dist to .gitignore.
Delete data/dist from git.
Error conditions reading data/dist just set the value to Default.
Remove a leftover TODO comment.
Add description comments for the two new database columns.
