Version 1.4.1 - Nowplaying status update

This minor version update adds the now-playing status message, which, at a
configurable interval, polls the Cadence Radio server for information on
the currently playing song, and sets it as the bot's status message. This
feature was suggested by @kenellorando.

This feature, if desired, can be disabled entirely, by setting the
interval to a negative number in config.json. This will set the
nowplaying information to 'Cadence Radio'.

Additionally, this version includes an update to the help message for
request, to be more inclusive of one-step-request.

Version 1.4.0 - One-step-request version

This version adds in One-Step-Request (OSR). OSR allows the user to instruct CadenceBot to attempt to discern which song (of the search results) to request. This is done by simply passing the string they'd search for to Cadence request. CadenceBot will attempt to choose a song to request from the search results using five filters, in order:

1. Trivial case (If Cadence returns a single result, choose it)
2. Title case (If exactly one result has a title which exactly matches the request, choose it)
3. Artist case (If exactly one result has an artist which exactly matches the request, choose it)
4. Title+artist case (If exactly one result has a title which exactly matches the beginning of the result, and an artist which exactly matches the end of the result, regardless of text in between, choose it)
5. Artist+title case (If exactly one result has an artist which exactly matches the beginning of the result, and a title which exactly matches the end of the result, regardless of text in between, choose it)

All comparisons done ignoring case, accents, and punctuation.

If these filters fail to choose a result, then the results are presented to the user as if returned by search and the user may request one via a normal second-step request.

---

Additionally, on the administrative end, Version 1.4.0 switches configuration to be stored in two files: default-config.json stores the default configuration, which is kept under version control so that working configuration is always present, and config.json, which is now outside version control, and optional (will be silently ignored if not present), and which stores a set of options which will override those set in the default configuration. Options that are not set here will be filled in from the default configuration.

Thus, server admins can now freely override the default configuration to their choosing, without any interference or hardship from the Git repository, even in case additional options are added.

Version 1.3.1 - Infinite reconnect bugfix

This commit fixes the issue with infinite reconnects, whose fix was introduced (untagged) before v1.3.0, and which reappeared in 1.3.0.
This bug would sometimes cause a seemingly infinite number of reconnect attempt messages to be sent to the text channel, along with the generation of a massive log full of constant messages related to these commands. This would occasionally not even obey stop, persisting until CadenceBot was stopped on the server or removed from the Discord guild.

I fixed this bug originally by adding a timeout between reconnects (30 seconds). However, as part of the upgrade to version 1.3.0, that is, as part of fixing #14 (multiple server support), this functionality was made specific to the voice channel (that is, each voice channel has its own timeout), and thus broken (by, specifically, the code which prevented the equivalent of null-pointer errors resulting from a lack of set reconnect information about the particular voice channel).
This version fixes that functionality - Reconnects are now disallowed within 30 seconds of any initiation of playback.

Version 1.3.0 - Multiple Server Support

This version pulls a number of significant 'under the hood' changes. Most notably, CadenceBot is now functional when being used on multiple servers simultaneously.

@JakobFrank and I have discovered one issue while testing these changes. This issue, however, appears on all versions of CadenceBot since requests were implemented (v1.2):
Cadence itself rate-limits requests to one request every five minutes (300 seconds), per IP address. This is great for the web client, because requests are made through the browser, and therefore come from the user's IP. The problem @JakobFrank and I discovered while testing these changes is, requests made through CadenceBot come from the server hosting CadenceBot, and therefore come from that IP (18.221.243.54 for the live server at the moment). That means that, while @JakobFrank and I can make two separate requests within five minutes via the web client, my request blocks him from making one through CadenceBot for five minutes (because the bot's IP is ratelimited).
That, however, isn't really a problem I can fix, at least not by myself - @kenellorando, we should consider finding a workaround for this, as I don't think its expected behavior, or intended behavior. I suppose it might be possible to exempt the CadenceBot servers from ratelimits, but that might not be optimal. Maybe we could do that but have the bot handle limiting? But that grants multiple requests via different platforms.
I dunno. It's @kenellorando's call, as it is his server to manage.

---

This version also brings the updated logging system to the live server (master branch). This means that all of CadenceBot's logs are generated with ANSI color coding to levels of severity, including second-precision timestamps and line numbers of origin. The logging format can be customized by editing the config file - configuring text colors can be done by editing the 'filters' section of the 'logging' section of the config file.
The log format itself can be edited via the 'format' parameter, and the format timestamps are recorded in can be changed via 'dateformat' - notably, milliseconds can be recorded by including 'l' in the format. I don't think that's necessary, so I don't have it, but someone might like it.

---

The final change included in this version is bitrate configuration. Until this version, CadenceBot has performed streaming at default settings. This version adds a 'bitrate' parameter to the configuration - CadenceBot will stream at the bitrate set there (the unit should be kbps), or it can be set to 'auto' to use the default bitrate used in the voice channel it joins.
In this version, I have set the bitrate to 96kbps. I think the default is 48, so this should result in a decent increase in perceived music quality, especially for songs which Opus finds difficult to compress. Hopefully @JakobFrank likes this setting, because I'm pretty sure its the maximum.

Version 1.2.1 - Bugfixes and setup improvements

This version pulls several bugfixes for ARIA integration and input validation. Additionally, stream end is now accompanied by an error message and a retry attempt, and generates a log entry including the error provided by Discord and the currently playing song (and the failure time). Neither @kenellorando or I have been able to find the source of these errors, so this will have to do.

Additionally, this version introduces the first-time-setup.sh script, which automates the process of setting up a new instance of CadenceBot. I realized while setting up the development instance that it was fairly difficult to correctly perform setup from memory, and it took a lot longer than I would have liked, so this script is now entrusted with managing the first-time setup, especially on systems which use apt as package manager. This means, notably, that if one of the AWS instances running the bots is brought down (say, by being hacked by hackers with Chinese IP addresses, as happened to Cadence itself, sort of), service can be restored simply by deleting the instance, creating a new one, cloning the repository, running the script, and starting the service. Its not trivial, but its damn close.

Also, this version fixes some errors npm was generating whenever installing a package, relating to a lack of fields in package.json.

Finally, this version introduces the ability to archive logs before they are deleted by restart.sh simply by writing the appropriate commands in maillog.sh - If this is not present, it is simply ignored. This script can optionally be generated by first-time-setup.sh.

Version 1.2 - Full ARIA Integration

This version implements making song requests through CadenceBot. I'm not entirely happy with the interface for this at the moment (I plan to work on it in the near future), but this version is functional.

As of this tag, CadenceBot is equal in function with the web client, on the current master. At the moment, that would be 1a6164f44c5edff49e437f2fecc99878268a8881.

Version 1.1 - Searchable Version

This version adds the ability to search the Cadence database using Aria (Cadence search followed by a search term).

This version extends function roughly equivalent to that Cadence had on September 29th, in 7d0da442229cd25ee529f45f58f5f64d52a9ded8.

Version 1.0 - Release Version

This version, incorporating the now playing command, is the first one which interacts with Cadence beyond as an audio player.

CadenceBot now matches the functionality of the web client on March 25th, in 8ab621cf538c3645ec04383f8578f4286f368c6c.

Version 0.9.1b - Help version

This beyond-minor version adds a help command (Cadence help).

While minor, this is kind of necessary for the bot to be deployed anywhere for people unfamiliar with it.

Version 0.9b - First working version

This version is the first which is capable of playing Cadence, and therefore, is the first that can do its job.