Reopen an issue on a new note from external participant

What does this MR do and why?

Contributes to Reopen Service Desk issues when an external par... (#8549 - closed)

Reopen an issue on a new note from external participant

Adds the backend logic and database field for this feature. Because the database field defaults to false it's not usable without the frontend settings part.

🎏 I intended to not add a feature flag because the feature is "hidden" behind a setting that defaults to false. We need at least two MRs to complete this feature, but because you cannot set the setting without the UI, I think adding the BE logic and later add the setting UI works without a feature flag.

Upcoming MRs

1. Add the newly introduced setting to the project Service Desk settings page.

Screenshots or screen recordings

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

Before	After
🚫

How to set up and validate locally

1. If you haven't set up incoming_email or service_desk_email for email ingestion, please add this to your gitlab.yml file in the development: section. Please restart GDK with gdk restart:

   incoming_email:
     enabled: true
     address: "incoming+%{key}@example.com"

   This will allow you to see the Service Desk section in the settings and generate project-specific email addresses.
2. Select a project and user and make the last issue in the project a Service Desk issue (or select one by yourself)

   project = Project.find(7)
   current_user = User.first
   issue = project.issues.last
   email = 'user@example.com'
   
   issue.update!(author: Users::Internal.support_bot, service_desk_reply_to: email)
   IssueEmailParticipant.create!(issue: issue, email: email)

3. Add a note so we get a reply key and can build a reply address. Replies to this address will now be matched with the issue and instead of creating a new issue it will post a reply to the existing issue.

   issue.reset
   note = Notes::CreateService.new(
     project, 
     current_user, 
     {
       noteable: issue,
       note: "note content"
     }
   ).execute
   
   reply_key = issue.sent_notifications.last.reply_key
   reply_address = ::Gitlab::Email::IncomingEmail.reply_address(reply_key)

4. Close the issue (via UI or console)

   issue.close!

5. (Optional) Assign the issue to one or more users. Assignees will be mentioned in the reopen comment.
6. Update the Service Desk settings, so it automatically reopens on a note from an external participant

   ServiceDeskSettings::UpdateService.new(project, User.first, reopen_issue_on_external_participant_note: true).execute

7. Build a reply from an external participant and ingest that email via the console.

   email_raw = <<~EMAIL
   From: user@example.com
   To: #{reply_address}
   Subject: Issue title
   
   Reply
   EMAIL
   
   EmailReceiverWorker.new.perform(email_raw)

8. Now browse to the issue and find the following:
   1. The reply comment of the external participant (user@example (external participant))
   2. The confidential reopen comment (mentioning the assignees)

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.