Enable emails and allow onwiki account verification

[dqwiki]

We need to start forcing the onwiki accounts to be user verified. Given #437 and the reason that caused it, it's looking like this lack of a feature is being exploited.

To get my thoughts flowing on this particular topic:

💭 Thinking tasks

• Figure out the best email method and document it (Likely: Use existing DQB email that already has autoreply)
• Consider where in the process emails need to be implemented
• To consider for future: MFA implementation with security code sent via email
• Think about email retention timeline, both from an anti-abuse perspective and a returning user perspective

💭 🏁 Thought Results

• Email method: We could ask to use WMCS infra, or use whatever existing infra exists. The problem with this method is that we have to setup a whole new method and the reputation will reflect that of the WMCS domain, and not our own. It seems better to continue to use the DQB email that is setup as a reply to when Special:EmailUser is sent, as that is already setup with an autoresponder, and we just need to authenticate with gmail. On further review, it looks like using an external API (with 3k free emails/month) would be the easiest way to do it - see https://github.com/spatie/laravel-mailcoach-mailer
• Reply to email: On further review, we will need our own domain for this. I will obtain one after I figure out a domain.
• When emails used in the process: It would be optimal if an email was confirmed before an appeal could be created, as it would reduce the number of appeals that get expired due to not confirming, and add an extra layer for account confirmation. Asking for an email after the fact would cause user frustration and wasted appeals.
• With email retention, the email will be disassociated from the appeal after 6 months from the time of the last comment after closure. Emails need to be retained indefinitely to handle spam/emailban concerns but there will be no connection to anything.

⚠️ Security tasks

• Allow an end user to ban their email with a tokened url
• Rate limit (similiar to the appealfor/ip limit)
• Setup .env of banned domains
• Ensure that user@wiki emailban entries are setup for when an appeal is created

Actionable tasks

• 🕙 Use Special:EmailUser as priority, email only as backup
• Create interface pages: IPs or accounts without a registered email/Email verification
• Create interface pages: Accounts with registered email/Special:EmailUser verification
• 🕙 Include both verifications of appeal and ban my own email from utrs links in that email
• 🕙 Implement Enable lost appeal key recovery #46 with spam protection
• Check and confirm that new mediawiki appeals remain, are in the same section, standardized and secure
• Cross Email ban logging with regular logs
• Allow tool admin to flip bans
• Log a reason for email ban change
• 🕙 Move email templates from mailcoach to laravel and check implmentation
• 🕙 Create developer template preview
• Stop IPs from generating wiki accounts on email table

Structure of Emails table

Passing	Format	Description
id	int	Email ID
email	text(size limit)	Email address requesting
linkedappeals	int[]	All appeals this email address is used
appealbanned	bool	If the email address is prohibited from being used in appeals
accountbanned	bool	If the email address is prohibited from being used for user accounts
lastused	datetime	When the email address was last successfully used for an appeal
lastemail	datetime	When the email address was last sent an email