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)?

[jzbahrai]

Currently all the failures are SES related. This is now Piinpoint related and we wanted to store that and make it obv. I think as we grow and add more providers/ clients/ - we should add failures according to those implementations so we might know exactly where the failure came from and not have to traceback through logs

[whabanks]

I agree with not tying statuses to functionality or vendor specific terminology. That said, properly achieving vendor agnostic terminology for statuses, while still improving observability would take some effort.

Since we're handling a conflict between a Request - send to intl. #, and the configuration of the target provider resource - pinpoint not configured for intl. sending, we could use something more generic like:

• PROVIDER_FAILURE
• PROVIDER_CONFLICT_FAILURE
• PROVIDER_VALIDATION_FAILURE

Then capture the vendor specific info + failure reason in the feedback_reason. To Jumana's point - the current solution does provide added observability while requiring minimal changes to existing infrastructure for the time being.