WIP: Extend SpamWatch integration

[ajhalili2006]

WORK IN PROGRESS, DO NOT CLOSE! Once I am finished the details here, you can comment. I am done editing stuff and feel free to review it.

About the Issue

Integrating it with SpamWatch on joins is good, but can we extend SpamWatch on the following suggestions:

• Checking the SpamWatch banlist status for user XXYYZZAABBCC when triggered the /user.
• Adding a way for admins to interact with the SpamWatch API without ever add extra code on their forks (adding a new /spamwatch command).

First Suggestion: Manually checking status of a user when admins triggered /user

When an admin triggers the /user command for user XXYYZZAABBCC, the server/machine where the bot is hosted should contact the SpamWatch API (defaults to api.spamwat.ch if undefined in config.js/config.json) for the status of the user if he/she is banned.

When checking for the ban status using this method, use the defined API token in the config as SPAMWATCH_API_TOKEN.

Second Suggestion: Adding new way of interacting the API without extra lines of code

This suggestion will add a new command for that, /spamwatch. The usage of that command describes below as it says. See the SpamWatch API docs for details.

Due to some restrictions and feedback from @SitiSchu, I removed and excluded some stuff that requires token management or editing the banlist.

Command	Fields	Description	Example
/spamwatch banlist	n/a	Get the full banlist, requires the Root permission.	spamwatch banlist
/spamwatch query	<uid or username>	Checks whatever the user is banned. Can be used in replies and use user <uid, username or reply> as shortcut	/spamwatch query 777000
/spamwatch about	<token>	Get API version of SpamWatch an number of active bans.	/spamwatch about
/spamwatch docs	n/a	Get the SpamWatch documentation link.	No usage example, because there's no fields needed.

Legends:

• < > = Required
• [ ] = optional

Notes

1. XXYYZZAABBCC represents a Telegram user's unique ID, generated after signup per user.
2. SPAMWATCH_API_TOKEN represents a valid, working SpamWatch API token. The API token should be there in the config file instead of manually sending it to the bot.
3. Because the ban list is SOOO LARGE and CONSTANTLY UPDATED, the bot server should cache the API response once every 6 hours unless --force flag is used and send the response as a JSON file.

[SitiSchu]

The first suggestion is good, I find the second one rather pointless.

1. Putting the Token in the command will force users to use it in pm
2. No bot should have a Root token so creating tokens with it is not possible anyway
3. Having a command for the docs doesn't make much sense
4. Getting the entire banlist is a bit heavy since its JSON, also I'm not sure why the bot would need a command for that

[ajhalili2006]

The first suggestion is good, I find the second one rather pointless.

1. Putting the Token in the command will force users to use it in pm
2. No bot should have a Root token so creating tokens with it is not possible anyway
3. Having a command for the docs doesn't make much sense
4. Getting the entire banlist is a bit heavy since its JSON, also I'm not sure why the bot would need a command for that

Okay. I'll note about that as this issue is an Work-in-Progress. Once this issue is finalized, then we can clear the stuff out, @SitiSchu.

[SitiSchu]

Having a command for the API documentation still doesn't make sense
The query command is kinda superfluous if /user shows the status anyway
No real reason to get the entire banlist with a bot command either