www: Email rate limit

[thi4go]

This diff adds a email rate limiter functionality for the mail package. It extendsclient with the rate limiting functionality. This is done in order to avoid malicious behaviour and avoid spams on the politeia's smtp server.

• Adds a Mailer interface to the mail package, providing an API to interact with the smtp client.

  • IsEnabled returns wether the smtp server is enabled
  • SendTo sends emails to anyone without rate limiting functionality
  • SendToUsers sends emails to politeiawww users with rate limiting functionality

• Adds a new email_histories table to the user database.

  • user_id as primary key.
  • blob containing the user's email history, which in turn contains the unix timestamps in which the last emails were sent in a 24h window for that user, and a bool to tell if the user has already received the rate limit warning email.

• Adds a MailerDB interface to the user package, used to interact with the email_histories table.

  • EmailHistoriesSave upsert email histories for the given users
  • EmailHistoriesGet retrieve email histories for the given users

• Adds a TestMailerDB interface to the user package, used to test the rate limiting functionality from the mail package.

The reason a new table was created for this, instead of just adding this data to the user object, was to avoid race conditions on database calls, since our user database currently does not support transactions, and email notifications run in a separate go routine. This will not be the case once the user layer gets rewritten.

closes #1398

[lukebp]

The code looks pretty good. Its clean and readable. I think you've go an issue with one of your design decisions though.

I gave this a high level review and will take a deeper look once the design issue has been sorted out.

[thi4go]

This is ready for another look mate @lukebp fixed the design issue.

[lukebp]

This still isn't right. Why do you have two different mail clients?

[thi4go]

@lukebp my bad, nuked limiter client and extended our existing client with the limiting functionality. Also created the user.MailerDB for a cleaner separation of concerns like we talked about, so that Mailer would not have unnecessary exposure to other userdb methods. Things look even more cleaner now 👍

[lukebp]

Overall design looks good. Most of my comments are related to formatting or documentation.

[lukebp]

This is looking much better. The code is clean and readable. I think the overall design looks good. There are still a couple parts I need to look at more carefully, but I've got to run. Remove the CMS bits and fix the comments. I'll give it a another review and test it once that's done.

[lukebp]

Update the original pull request message too with a more in depth breakdown. It should describe from a high level the interfaces that you added, the fact that this is a new databaes table instead of adding it to the user object, and why we chose to do that.

[thi4go]

Done @lukebp, removed cms bits, addressed the remaining comments and updated the PR message 👍

[lukebp]

ACK