Add @guardian/cdk to repository and deploy stage-specific templates

[jacobwinch]

What does this change?

We are migrating the mobile-save-for-later service from CloudFormation to @guardian/cdk. The migration will involve 5 PRs:

1. Add @guardian/cdk to repository; update CI & deployment wiring accordingly [this PR]
2. Provision a new version of the infrastructure using @guardian/cdk (Add cdk-defined version of API infrastructure #65)
3. Move DNS configuration from CloudFormation into @guardian/cdk (but continue routing requests to old infrastructure) (Move domain name configuration from CFN to cdk #66)
4. Update DNS configuration (start routing requests to new infrastructure) (Route all traffic to the cdk-defined infrastructure #67)
5. Remove old infrastructure (Remove superfluous resources - these have been replaced by GuCDK versions #73)

In this PR, we 'wrap' the existing CloudFormation with @guardian/cdk, following the process described here.

Note that all changes in 6179bb0 are auto-generated by @guardian/cdk project creation tooling; I would not spend much time reviewing this in detail!

There are, however, a couple of changes that require a little more explanation:

1. Original CloudFormation has been converted from AWS::Serverless-2016-10-31 to 'standard' CloudFormation (1389750).
   • This is to work around an issue described in this comment: (cloudformation-include): detect cycles in the input template aws/aws-cdk#16654 (comment). In order to do this I downloaded the processed template via the AWS UI.
2. We now deploy two separate templates (i.e. there is one file for CODE and a different file for PROD), instead of a single template for both stages (ad96d92).
   • This is the way that @guardian/cdk has chosen to deal with multiple stages. For motivation see: https://github.com/guardian/cdk/blob/main/docs/architecture-decision-records/006-stage-awareness.md. As it stands the contents of these templates are identical, but that will change in the second PR of this migration process.

How to test

I've deployed this to CODE and used a debug version of the app to confirm that saving articles/viewing saved articles still works as expected. (I checked the AWS Lambda logs and DynamoDB to confirm that server side code was being exercised as expected).

How can we measure success?

We have started the migration process to @guardian/cdk.

Have we considered potential risks?

This PR should be pretty low risk; we are changing CI and CD wiring, but the actual infrastructure serving requests will not change substantially (i.e. we just change the metadata by adding some new tags).

[akash1810]

I added a new build step in TeamCity (i.e. outside of version control)

Could we bring the CI build steps into the VCS? We're currently using the sbt runner in TeamCity, which IIRC isn't great as it always exits 0, even when there are failing tests 😱 .

[jacobwinch]

Could we bring the CI build steps into the VCS? We're currently using the sbt runner in TeamCity, which IIRC isn't great as it always exits 0, even when there are failing tests 😱 .

Sure, will raise a new PR for that and then rebase this one.

Update: this has been done in #68.

[waisingyiu]

Look great to me!