[ECR Public] [request]: Metrics for public traffic to ECR Public repos

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
My team owns several public ECR repos, and we'd like metrics about download traffic. The only two currently-available mechanisms like this are

* [ECR usage metrics](https://docs.aws.amazon.com/AmazonECR/latest/userguide/monitoring-usage.html), which only reflect activity from within the AWS account where the repo is hosted
* The ECR Public Gallery lists a rounded aggregate number of public downloads but does not break this information down by time period or by image

We would like ECR to give repo owners statistics about download activity occurring on their repos from outside the owner's AWS account. Some proposals on how to accomplish this:

1. Provide a daily or hourly S3 dump of all download activity for each repo, broken down per image.
1. Perhaps also include the last pulled date for each image: see https://github.com/aws/containers-roadmap/issues/1182
2. Emit CloudWatch metrics on a 5-minute or 1-hour cadence with aggregate or per-image download statistics

**Which service(s) is this request for?**
ECR

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
We recently had an event where we inadvertently modified most of the manifests in an ECR repo but it took us much longer than necessary to notice the problem and address it. If we had the metrics described in (1), we would have had a better estimate of blast radius before executing the change, and with metrics described in (2) plus CloudWatch anomaly detection, we could have detected the problem within an hour for a faster mitigation time.

**Are you currently working around this issue?**
The existing metrics do not satisfy either problem.

**Additional context**

**Attachments**