WIP: Resolve "Spike: Email Integration for Alerts"

What does this MR do?

This MR implements a quick and dirty Email integration for Alert Management, hence the word "Spike" (see #217178 (closed)). It can inspire future implementations for #214525 (closed).

Implementation details + questions

• A new email handler (Gitlab::AlertManagement::IncomingEmail::CreateAlertHandler) (see https://docs.gitlab.com/ee/development/emails.html#incoming-email for more context)
  • ❔ Leave it namespaced or move to Gitlab::Email::Handler::CreateAlertHandler
  • ❔ Improve error handling (currently just InvalidRecordError with message from service)?
    • If "Alerts integration" processing an email is a noop - see TODO
  • ❔ Should we allow GitLab Flavored Markdown?
• Mail handler uses a short version of the token from "Alerts integration" -
  • ❔ "Option 2" from #214525 (comment 354720971)
• The email handler calls Projects::Alerting::NotifyService passing email subject and body
  • ❔ Use email date as starts_at
  • ❔ Support monitortool specific email templates
• Mail handler includes ReplyProcessing
  • ❔ Alert Bot was chosen as author. OK?
  • ❔ Check the "quick action" abilities with this module
• Just one happy path spec
  • ❕ Add more!
• Alerts integration is incomplete
  • ❕ Pass incoming_email_address to frontend and add a copy button
  • ❕ Add incoming_email_address to API so Reset token also updates the "Email address"
  • ❔ Edge cases when inactive/fresh
• docs-missing
  • User documentation
  • Dev documentation

Screenshots

Alerts integration	Mail client	Alert details	Incident issue

Try it

• Checkout this branch
• Configure "Incoming email" as described in user docs or dev docs
• Start GDK
• Start mail_room
• Create a project and enable Settings > Integrations > Alerts endpoint
• Use the Email address from the settings page to send a test mail
• Watch GitLab creating an Alert ("Category:Alert Management") and Incident Issue ("Category:Incident Management")
• 🎉

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team