Adds Service Desk settings custom email component skeleton

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?

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

This MR adds the CustomEmail component skeleton to the ServiceDeskRoot component. The skeleton includes the initial resource fetching from the new CustomEmailController (GET) endpoint. The endpoint is for a single resource and supports all HTTP verbs. In upcoming MRs we'll use other HTTP verbs, but use the same URL.

1. CustomEmail only renders when Service Desk and the feature flag 🎏 service_desk_custom_email is enabled.
2. It renders a card with header, body and footer (with link to feedback issue).
3. A loading spinner is visible while we fetch the resource.
4. After the resource has been fetched (no custom email configured), the body is empty.
5. On network error a toast displays an error message.

Screenshots or screen recordings

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

Screenshot (after resource fetching) for Technical Writing.

⚠ Since grouprespond and Category:Service Desk do not have a dedicated UX designer, it's recommended to move on without UX review for now. So we won't ask for UX review for this MR.

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.

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

3. 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.

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.