Use pinpoint for designated templates

[sastels]

Summary | Résumé

We add two main features here:

• Use an AWS Pinpoint pool to send messages from specified templates (other templates not affected).
• add a task to process pinpoint delivery receipts

This code can be merged in and will sit unused unless

• the required env vars are set
• an sms is sent using one of the designated templates.

In other cases the normal sns code will be used to send the text.

Related Issues | Cartes liées

• https://app.zenhub.com/workspaces/notify-planning-core-6411dfb7c95fb80014e0cab0/issues/gh/cds-snc/notification-planning-core/286

Test instructions | Instructions pour tester la modification

• set your AWS_PINPOINT_SC_POOL_ID env variable to the pool id in staging AWS_PINPOINT_POOL_ID = "pool-b20333ce1e4e49309ba1db3bf94a3f57"
• set the env var AWS_PINPOINT_SC_TEMPLATE_IDS to a list of your sms template ids. Just one is ok, ie AWS_PINPOINT_SC_TEMPLATE_IDS = 000000-1111-2222-3333-444444444
• send an sms using a template in the list. You should see a line such as AWS Pinpoint request finished in ... in the celery logs
• send an sms using a different template. Instead of the Pinpoint line you should see AWS SNS request finished in ...
• note that both sends could be from the same number.

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]

Nice documentation to have in the code!

[sastels]

I think this is the cleanest way to use matching, but I think it's even better with if/elifs:

    if "blocked" in response_lower:
        return NOTIFICATION_TECHNICAL_FAILURE
    elif "invalid" in response_lower:
        return NOTIFICATION_TECHNICAL_FAILURE
    elif "is opted out" in response_lower:
        return NOTIFICATION_PERMANENT_FAILURE
    elif "unknown error" in response_lower:
        return NOTIFICATION_TECHNICAL_FAILURE
    elif "exceed max price" in response_lower:
        return NOTIFICATION_TECHNICAL_FAILURE
    elif "phone carrier is currently unreachable/unavailable" in response_lower:
        return NOTIFICATION_TEMPORARY_FAILURE
    elif "phone is currently unreachable/unavailable" in response_lower:
        return NOTIFICATION_PERMANENT_FAILURE
    else:
        return None

[jimleroyer]

Yeah the match case isn't the most terse I have seen in a language unfortunately. I hope Python improves on that. I wouldn't mind the if...elif...else. :\

[jimleroyer]

Not sure we need this return statement here.

[sastels]

🔥

[jimleroyer]

🥳