feat: use cloudfront as cdn

[jiegec]

To fix #9

• use cloudfront as CDN to distribute entire site, use the ALB as origin
• different cache policies for different content
• support custom domain and SSL certificate(NOTE: ACM certificate not supported used by CloudFront in China regions, use IAM cert as workaround) via context parameters
• update domain records in r53
• unit tests
• update readme

Will do later:

• custom cloudfront invalidation for web portal

[zxkane]

Let's update cdk to 1.55.0 to pick up feature and bug fixes for cloudfront.

https://github.com/aws/aws-cdk/releases/tag/v1.55.0

[jiegec]

What cache policies is needed:

1. Content server and web portal can have a larger cache time
2. /static/tunasync.json should have a small cache time or none

When custom invalidation is needed:

1. index files (like InRelease of debian, ubuntu etc) can be invalidated as soon as they are changed

[zxkane]

I propose below cache policy,

• default 1 day cache for the alb origin
• override cache policy via upstream http headers
  • yum/debian repos
    • short cache time for package database files, such as 30/60m,
    • long cache time for binary files, such as 1y
  • short cache time for tunasync.json, such as 5/10m
  • other repos using default policy of cloudfront, let's polish their policies in future
• invalidate the web portal after new deployment via custom resource
  • use image hash as custom property
  • specify the paths of web server to be invalidated

What cache policies is needed:

1. Content server and web portal can have a larger cache time
2. /static/tunasync.json should have a small cache time or none

When custom invalidation is needed:

1. index files (like InRelease of debian, ubuntu etc) can be invalidated as soon as they are changed

[zxkane]

CDK v1.56.0 is introduced lots of cloudfront changes. Let's adopt it.

https://github.com/aws/aws-cdk/releases/tag/v1.56.0

[zxkane]

@jiegec let me know if you have any comment for new commits.