Limit /check_api Invocations to Once Every 15 Minutes per Server

[ThorntonMatthewD]

Fixes #5

Summary

This change only allows for the /check_api command to be run on a server/workspace every 15 minutes. If a user from a workspace that has run this command within 15 minutes runs it again, they'll be greeted with this message:

"This command has been run recently and is on a cooldown period. Please try again in a little while!"

Cooldowns are specific to each workspace, so users from one server aren't subject to a cooldown being enforced against another.

I've also extracted out the instantiation of the SQLite connection(s) from bot.py to database.py to make testing database-dependent functionality a little bit easier.

Screenshots

A record in the cooldowns table where each server (or anything whose ID we'd want to put here) has a timestamp denoting when someone from there can run /check_api again.

What end users see if they hit the rate-limit.

Test Plan

1. Fire up the bot locally and run the /check_api command in a workspace that your bot is integrated with.
2. Check for a new record in the cooldowns table.
   1. The accessor field will be the subdomain related to your workspace (<accessor>.slack.com).
   2. The resource field will be check_api.
   3. The expires_at time will be a timestamp in ISO8601 that should be the time 15 minutes from whenever you executed the /check_api command (in UTC).
3. Try running the command again. You shoud receive a message about how the command is on cooldown.
4. Adjust the expires_at timestamp to be an hour behind what it's currently set to and commit your change. Then try running the command again (it should work).
5. Extra spicy: If you have access to another workspace, verify that the timers are enforced on each server independently (Server B doesn't have a cooldown but Server A does).

I think it would also be good to test the other end-user-facing functionality (like /add_channel and /remove_channel just to ensure the DB refactor didn't booger anything up.

[ThorntonMatthewD]

I moved the DB-related calls to the database.py file to simplify testing a bit (so I could create a fixture to clean the DB between tests).

[ThorntonMatthewD]

I debated making this an ``autouse=true` fixture, but for now I've elected to keep it so that it needs to be manually included into tests. It'll wipe all of the rows from all tables at the end of a test (the schema is left intact, though).

[ThorntonMatthewD]

I'm still working through how to stub out the actual Slack bits in the test suite. It's making things a bit interesting in the meantime. 😅

I'd love to come back and refactor this to make some more explicit assertions once any interaction with Bolt doesn't cause a 401 error to be raised.

[oliviasculley]

Tested this on an environment from dev and it works great! The database changes make things a lot cleaner and this is a great feature to have, thank you!

[ThorntonMatthewD]

Thank you for reviewing, @oliviasculley!