Adds Service Desk custom email verification model changes

Feature context

Click to expand 👇

Right now it is not possible to customize the Service Desk email address (intake and sending) in its entirety. On self-hosted instances you have more control over the used addresses, but you will still have a rather cryptic target email address for a specific service desk in a project. For .com users it's currently not possible to customize the Service Desk email at all.

There is a proposal and a further exploration around this issue. A summary of the solution path is the following: Users set up their custom email to forward all emails to the cryptic Service Desk email and provide SMTP credentials so we can send emails on their behalf. This way customers seeking support will only see the custom email address in their communication.

There is further discussion about improving and changing the general infrastructure, but this approach is a MVC to solve the issue for our customers.

🗺 How does it contribute to the whole feature?

This MR is the second part in a series of MRs that will follow in order to complete this feature. See #329990 (comment 1227384943) for a detailed breakdown. Here's a summary:

1. ✅ Using SMTP credentials. Foundation work. Add Service Desk custom email foundation (!108017 - merged)
2. 🎯 Verify email ownership, correct function and setup Part 1
3. Ingest replies from custom email
4. Add settings and validation to Settings page
5. Add documentation

The feature is behind the Feature Flag service_desk_custom_email [Feature flag] Rollout of `service_desk_custom_... (#387003 - closed)

What does this MR do and why?

This MR is the first part of the second task for Configurable e-mail address for service desk (#329990 - closed) and adds custom email address verification database fields and model methods.

I adds database fields to service_desk_settings so we can persist the verification state in every moment.

1. custom_email_verified is true if the current credentials could be verified successfully
2. custom_email_verification_running is true if a verification is currently running in whatever state
3. custom_email_verification_token holds a 12 digit sequence we use to verify the ownership. Will be nil whenever no verification process is running.
4. custom_email_verification_triggerer_id is the user that initiated the verification process. We use this to protocol the triggering user and to also send progress emails to the triggerer.
5. custom_email_verification_triggered_at is the time where the verification process was started. We allow 30 minutes to pass until we mark the process as failed.
6. custom_email_verification_error is an enum that persists the last verification error. See the model for options.

How to set up and validate locally

No special steps here, as only database migrations and model methods are involved.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.