Adds Service Desk settings custom email verification started state

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 part of 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.
2. ✅ Verify email ownership, correct function and setup
3. 🎯 Add settings and validation to Settings page.
   • Backend
     1. ✅ Create and Destroy Services
     2. ✅ CustomEmailController
   • Frontend
     1. ✅ CustomEmail component foundation with initial resource fetching
     2. ✅ CustomEmailForm component with resource saving
     3. 🎯 CustomEmailStateStarted and CustomEmailConfirmModal components (with resource deletion)
     4. 👷🏻 CustomEmailStateFailed component (with resource deletion)
     5. 🚫 CustomEmailStateFinished component with resource update
4. Ingest replies from custom email
5. 👷🏻 Add documentation

What does this MR do and why?

⚠ Adds Service Desk settings custom email form co... (!128095 - merged) is a merge request dependency and this MR targets the dependency's branch to clean up diffs. Once !128095 (merged) has been merged, I'll rebase this MR on the current master. Rebased on master

🎏 This feature is hidden behind a feature flag and not used on production yet.

This MR introduces the following:

1. CustomEmailConfirmModal component that displays a generic confirm modal for resetting the custom email configuration (will be reused by buttons on all other upcoming state screens)
2. CustomEmailStateStarted component that's the screen the administrator will see when they saved the custom email configuration until the verification transitioned into the final states failed or finished.
3. Additions to CustomEmail component. Adds the above mentioned components and wires everything up. Adds resource deletion methods. Saving the custom email configuration triggers a verification process, where we send a verification email to the custom email using the provided SMTP credentials. While we wait for the process to finish, the CustomEmail component will poll the resource endpoint every 8 seconds for updates.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

There are no before/after screenshots, because the components/screens are new.

Verification state started screen after the custom email configuration has been saved successfully:

Confirm modal. Confirms resetting and deleting the current custom email configuration. Please note that this modal will be reused by all other state screens (failed and finished, handled in future MRs):

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Turn on (at least) incoming_email in your gitlab.yml so you can use Service Desk. You can add an example configuration, it doesn't matter for this MR. The below should do the trick. If not copy the full config of incoming_email from the production section:

   incoming_email:
    enabled: true
    address: "gitlab-incoming+%{key}@gmail.com"

2. Enable service_desk_custom_email feature flag 🎏, e.g. for Flight project:

   Feature.enable(:service_desk_custom_email, Project.find(7)) # or your project id

Now you have two options: 1) provide correct credentials, so the verification doesn't fail immediately or 2) fake-set-up a custom email configuration in the started state:

Provide correct credentials

1. Browse to http://127.0.0.1:3000/flightjs/Flight/edit and expand the Service Desk section and find the custom email card below the general settings.
2. Fill in the fields and save the configuration
3. You should find a verification email in the custom email inbox and if you set up email forwarding (not necessary to test this MR) also in the forwarding target.

Fake-set-up custom email in started state (recommended):

1. Add an example configuration in the started state via the rails console bin/rails c assuming project id 7:

   project = Project.find(7)
   current_user = User.first
   custom_email = 'support@example.com'
   
   setting = ServiceDeskSetting.find_or_create_by!(project_id: project.id)
   setting.update!(custom_email: custom_email)
   
   credential = ServiceDesk::CustomEmailCredential.create!(
     project_id: project.id,
     smtp_address: 'smtp.gmail.com', # we need a valid smtp address
     smtp_port: 587,
     smtp_username: custom_email,
     smtp_password: 'supersecret'
   )
   
   verification = ServiceDesk::CustomEmailVerification.new(
     project_id: project.id
   )
   verification.mark_as_started!(current_user)

2. Browse to http://127.0.0.1:3000/flightjs/Flight/edit and expand the Service Desk section and find the custom email card below the general settings.

continue

1. See the CustomEmailStateStarted component is being displayed
2. Open the developer tools and see that the resource is being updated every 8 seconds via a backend API call.
3. Select Cancel & reset custom email and see the CustomEmailConfirmModal being displayed.
4. Select Cancel or X and see that the state didn't change and there was no API call to delete the resource.
5. Select Cancel & reset custom email again and then Reset custom email and delete credentials and see a DELETE API call in the developer tools. In the app the form should be displayed and the toast message Reset custom email address. should appear.

If you're stuck and you'd like to delete the current configuration use this snippet:

project = Project.find(7)
current_user = User.first
::ServiceDesk::CustomEmails::DestroyService.new(
  project: project,
  current_user: current_user
).execute

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.