Unsubscribe individual issue email participants from issue

What does this MR do and why?

Contributes to External participants are notified when added a... (#299261 - closed)

❗ Although the code itself is not hidden behind a feature flag, adding more than one external participant to an issue is hidden behind the feature flag 🎏 issue_email_participants.

The feature flag will introduce multiple email participants on issues (specifically on Service Desk issues). They can be managed using the quick actions /invite_email and /remove_email. Users can also configure their project that GitLab automatically adds CCed emails to the Service Desk issue. Each email participant receives a Service Desk email when a new public comment has been added to the issue. This email also includes an unsubscribe link if the email template contains the specific placeholder.

This MR aims to allow a specific email participant to unsubscribe from the issue using the unsubscribe link generated in Service Desk thank_you and new_note emails.

Before, clicking the link would always unsubscribe the external author of the issue.

Additionally, when an external participant adds a note to an issue, we don't send Service Desk notification emails to the author of the note anymore. Previously we only excluded the external author of the issue. In setups with multiple external participants, this led to duplicate deliveries.

Also fixes Flaky test in spec/mailers/emails/service_desk_... (gitlab-org/quality/engineering-productivity/flaky-tests#69)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

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

🚫 backend only

How to set up and validate locally

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

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. You won't be able to ingest emails, but we don't need that here.
2. Select a project and enable the feature flag for issue_email_participants.

   project = Project.find(7)
   
   Feature.enable(:issue_email_participants, project)

3. Make an issue in that project a Service Desk issue

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

4. Navigate to the issue and add another email participant using this quick action

   /invite_email other@example.com

5. A system note should state that the participant has been added.
6. Now add a public comment to the issue using your logged in user. The content doesn't matter. Ensure that the notification emails have been sent (letter opener), so we know the background job has been performed.
7. Back in the console, find the SentNotification entry for the newly created email participant and construct the unsubscribe URL (or take the URL from the email to other@example.com in letter opener).

   issue.reset
   participant = issue.issue_email_participants.find_by_email('other@example.com')
   sent_notification = issue.sent_notifications.find_by(issue_email_participant: participant)
   "http://127.0.0.1:3000/-/sent_notifications/#{sent_notification.reply_key}/unsubscribe"

8. Call the url. You should see a success message.
9. Now verify the participant has been removed, but the external author is still present.

   issue.reset.issue_email_participants