Make sendPolicyAnnouncementJob more robust

[rosalieper]

This adds additional try-catch logic to make running this more robust.

It specifically adds a test for a real error we saw caused by attempting to email
a malformed email address.

It does not record to the DB successful emails but it does add log output that
will be persisted in GCE for longer than the mailgun logs.

Bug: T432211

[tarrow]

I think it's important to note @outdooracorn was suggesting either add the try-catch or use Queueable on the notification.

What we learnt so far is that testing if adding either of these two things makes the situation more robust is harder.

If we use Notification::fake() all notifications, even to users with malformed email addresses, appear to work because it's the process of actually sending the email that fails.

We also learnt that by default notifications use MailMessage (a subclass of SimpleMessage) rather than a complete Mailable. This means that testing with Mail::fake() is also not possible

[tarrow]

There is also a wiki_notification_sent_records table in the database with the idea being that we record each type of Notification that we send out in the database so that if there is an error we have a record of what Notifications were sent to Mailgun. Given that we are already part way through sending these emails, I don't think it's worth investing in that for now.

We had a look at this and realised that this table is for notifications about Wikis to be sent to managers. It doesn't seem to be useful from the perspective of just Users entirely independent of Wikis. For example, it really needs a wiki_id which we don't have in this situation.

We did discuss if we ought to implement a new table to track these changes but figured that this would add yet more time when we want to prioritise getting these mails sent out and we also want to stop thinking about this topic in general.