fix: lower 404 ttl to decrease end user failures

The user adds content to IPFS node, then tries to fetch it in a browser before sharing link with a friend.
For gateways backed by Saturn L1s (which use IPNI DHT proxy), we hit a problem. Different Saturn L1s will ask IPNI for the same CID multiple times.
When one L1 fails, Caboose (Saturn Client) will retry  using a different L1, and that will also fail due to cached 404.
User will try to refresh the page, and it will  fail again because there is no L1 that can find providers for the next ~300 seconds.
User is unable to fetch content which is available on DHT for the next 6 minutes, and will report IPFS is slow  / flakey, while in reality, a HTTP cache on centralized service is set too high, and that is all.

Proposal:
Lowering this to 5s should still protect you from unwanted load spikes,
but will fix false-negative content routing errors for end users.

Author: lidel

deploy/infrastructure/prod/us-east-2/cloudfront.tf

@@ -53,7 +53,7 @@ resource "aws_cloudfront_distribution" "cdn" {
 
   custom_error_response {
     error_code            = 404
-    error_caching_min_ttl = 300
+    error_caching_min_ttl = 5
   }
 
   default_cache_behavior {