Is your feature request related to a problem?

I had a meeting with @simi to follow up and continue the draft
@segiddins started on #3560 and here let's break down the problem.

Problem: The actual DownloadGem does not offer granularity or insights to the team creating the gem. The idea is improve the support giving more granularity and details about the user behavior while installing the gems.

Describe the solution you'd like

Introduce a new granular track of downloads. Allowing users to know more details of when gems will are installed and expose publicly more statistics about gems being downloaded.

The gem page can present daily, weekly monthly totals. The public view can also see hourly downloads of "Today".

The ideal scenario would also include the location from where the Downloads comes from but I haven't investigated enough if we have such granular level of information available.

Describe alternatives you've considered

I haven't checked alternatives as Postgresql is already in the stack and TimescaleDB was already the suggestion.

Additional context

I'm very glad to work and support RubyGems. I'm a rubyist for almost 2 decades and last 3 years I moved to work at Timescale as a Developer Advocate, the company behind the TimescaleDB extension. I also created the timescaledb gem. So, my plan is break it down in a few PRs:

1. Introduce the Timescaledb to the stack setting up tests and creating the new Downloads hypertable.
2. Track downloaded gems and introduce a clone of the Fastly job that just stores the data on timescaledb
3. Introduce the continuous aggregates for storing totals for downloads in daily, monthly, yearly timeframes
4. Backfill data from all s3 buckets
5. Migrate front end statistics to use the continuous aggregates
6. Clean up old statistics and counters