Fix/privatisation quickie interaction

[alexanderleegs]

This PR fixes an issue with the integration of privatisation with quickie. To be reviewed in conjunction with PR#1763 on the frontend repo. There are two existing issues being tackled by this PR:

• Repos which are being made private/unprivate should also affect their respective staging-lite sites, otherwise a site might still contain a publicly accessible version in staging-lite
• Our DB automatically self corrects to switch any site which has been placed on quickie via growthbook to the staging-lite. variant, but this should not be true for private sites

Note that this PR does not handle the issue of inconsistent states fully right now - it is possible that a user who attempts to privatise/unprivatise a site will have the request to the second amplify site fail, leaving us in an inconsistent state - this needs to be manually resolved for now, as the resolution is complicated. We can look into making this more robust if we find that this is a consistent issue, but I am opting to leave this as is for now and pipe alarms that notify us instead. The issue is also fixable on the user's end if they try again - the inconsistent state will not block cms operations.

TODOs:

• Add cloudwatch alarm for inconsistent state resolution
• Add entry in runbook for handling inconsistent state

Tests

• Privatise a site
  • Ensure that the staging and staging lite sites on amplify get updated with the password
• Deprivatise a site
  • Ensure that the staging and staging-lite sites on amplify have removed password

[seaerchin]

lgtm with one question

[seaerchin]

do we have an alarm for this? otherwise, we won't know when this occurs until someone feedsback to us, rendering this log moot

[alexanderleegs]

Hey yup the alarm's already been set up!
https://ap-southeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-southeast-1#alarmsV2:alarm/cms-backend-prod-node18-privatisation-inconsistency-error?~(search~'privatisation)