Invalidate CloudFront Cache when republishing engine files with same engine hash

[janpio]

#10312 was caused by a caching layer in front of our engine file distribution, that did not get updated when we reuploaded the same engine version (78a5df6def6943431f4c022e1428dbc3e833cf8e) via a new build of the same commit hash (https://buildkite.com/prisma/release-prisma-engines/builds/1768 vs https://buildkite.com/prisma/release-prisma-engines/builds/1767).

The solution was to manually invalidate the CloudFront cache that sits in front of the S3 bucket where we store these files.

We should integrate invalidating that cache when we re-upload already existing Engine files so this is automated.

[janpio]

Internal discussion links with more information:

• Discussion about how to fix: https://prisma-company.slack.com/archives/C016KUHB1R6/p1637160267082100
• What is happening: https://prisma-company.slack.com/archives/C02JRNJJ5DL/p1637159364003100
• Another case where this was caused by restoring a deleted patch branch: https://prisma-company.slack.com/archives/CEYCG2MCN/p1668151647352479

[janpio]

Example Invalidation rule for the Cloudfront distribution:

/all_commits/694eea289a8462c80264df36757e4fdc129b1b32*

This "invalidate[s] a directory, all of its subdirectories, and all of the files in the directory and subdirectories", in this case for engine hash 694eea289a8462c80264df36757e4fdc129b1b32 in all_commits.

[Jolg42]

Note: We do not have a fully reproducible builds (so rebuild means new SHA hash for example)
We think that one of potentially many causes is:

because we're not locking the build image when building
https://prisma-company.slack.com/archives/C02JRNJJ5DL/p1637159364003100