Add feedback_reason column to the notification table

[whabanks]

Summary | Résumé

This PR adds a new column, feedback_reason, to the notifications table. It will be leveraged to track more granular reasons why a notification fails. It also adds a new notification_status pinpoint-failure.

E.g. boto validates that the requested resource on AWS can handle the request being made through it. Since we disabled international sending in Pinpoint boto will throw an exception.

Related context that led to this decision

Test instructions | Instructions pour tester la modification

1. Tests pass
2. flask db upgrade and flask db downgrade work locally

Release Instructions | Instructions pour le déploiement

None.

Reviewer checklist | Liste de vérification du réviseur

• This PR does not break existing functionality.
• This PR does not violate GCNotify's privacy policies.
• This PR does not raise new security concerns. Refer to our GC Notify Risk Register document on our Google drive.
• This PR does not significantly alter performance.
• Additional required documentation resulting of these changes is covered (such as the README, setup instructions, a related ADR or the technical documentation).

⚠ If boxes cannot be checked off before merging the PR, they should be moved to the "Release Instructions" section with appropriate steps required to verify before release. For example, changes to celery code may require tests on staging to verify that performance has not been affected.

[jimleroyer]

Let's name the status to untie from a specific technology. We could go back to AWS SES or we could support Twilio as well and other providers. Is there a way to name this without depending on the implementation (and extend the model on an abstract name)?