Setting a Cc or Bcc address in the mail configuration causes emails to be resent at each restart of the server

I think the issue is more generic than notifications and generally related to mailing with the async mail API, but I have reproduced it with notifications, so here are the steps:

1. in the administration of the wiki, set an address in the field "bcc email addresses"
2. have 2 users available, User A and User B
3. setup notifications mails frequency to "realtime" for User B and have him activate Mentions notifications by email
   
4. in a comment of a page, have User A mention User B
5. after a while, user B receives an email about this mention (can be as long as 10 minutes or so)
6. the email is also delivered in the Inbox of the address specified as Bcc .

Expected result:
In administration, in the emails status, there is no failure stored and no unsent status stored. A success status is stored for this email if the email configuration "discard success statuses" is set to "no".

Actual result:
In administration, in the emails status, there is an "unsent" status stored for the email that user B just received. The status stored is prepare_success:

(the destination column has 2 email addresses in there, anonymized: one is the address of User B, one is the Bcc address).

The issue with this prepare_success status is that all emails with this status are considered incorrectly sent and are resent on server restart or when the scheduler job is triggered (as per XWIKI-13991 or XWIKI-17967). As far as I could investigate, how these duplicate emails are actually displayed in the Inbox of the receiver depends on the email server / client, as they are actually the exact same email sent multiple times, so the client may not show it as a new email.

If email success status is configured to not be discarded, 2 statuses will be stored for this email: one with prepare_success and the other with send_success:

(the destination column for both these lines has 2 email addresses in there, anonymized: one is the address of User B, one is the Bcc address).

As far as I could explore the behaviour of my instance before the upgrade to 13.4.x , this looks a lot like a regression, but I don't have enough information to fully mark it as such.