Include created_at in compact index /info endpoint

[marcbest]

Problem

Supply chain attacks targeting package registries are a growing concern. Other package managers have already shipped minimum age features — npm, pnpm, and yarn all allow users to reject recently published versions during resolution.

Bundler currently has no equivalent. Adding one requires knowing when each gem version was published, but the compact index has no publication timestamp. Without it, clients must make a separate V1 API call per gem (/api/v1/versions/<gem>.json) — adding seconds of latency and hitting the RubyGems.org rate limit (10 req/s) on projects with 50+ gems.

The compact index /info endpoint already carries all the version data Bundler needs during resolution — except created_at.

Solution

Pass the version's created_at (already in the SQL query) to CompactIndex::GemVersion.new as the 8th argument, formatted as ISO 8601 UTC.

Before:

name, platform, checksum, info_checksum, ruby_version, rubygems_version, = r
CompactIndex::GemVersion.new(name, platform, Version._sha256_hex(checksum),
  info_checksum, deps, ruby_version, rubygems_version)

After:

name, platform, checksum, info_checksum, ruby_version, rubygems_version, created_at, = r
CompactIndex::GemVersion.new(name, platform, Version._sha256_hex(checksum),
  info_checksum, deps, ruby_version, rubygems_version, created_at&.utc&.iso8601)

The created_at column is already selected in the requirements_and_dependencies query, included in the GROUP BY, and used for ORDER BY. It just wasn't being passed through.

Info line output

1.0.0 rack:>= 1.0|checksum:abc123,ruby:>= 2.7.0,created_at:2024-05-01T12:00:00Z

Old clients ignore unknown requirement fields, so this is fully backwards compatible.

Dependencies

Requires rubygems/compact_index#183 — adds created_at as an optional 8th field to GemVersion struct.

[hsbt]

📝 We need to pick rubygems/compact_index#183 into this PR after merging #6404

[tenderlove]

@marcbest do you mind rebasing? If looks like #6404 landed

[colby-swandale]

@hsbt where are we at with the cooldown discussion on RubyGems CLI? Is this work going ahead? Any idea on timeline?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.50%. Comparing base (72312b4) to head (64ae839).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6380      +/-   ##
==========================================
- Coverage   97.06%   94.50%   -2.56%     
==========================================
  Files         494      494              
  Lines       10502    10562      +60     
==========================================
- Hits        10194     9982     -212     
- Misses        308      580     +272     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hsbt]

@colby-swandale ruby/rubygems#9113 is only place that. But I haven't decided how to implement the cooldown option/configuration yet.

[hsbt]

We need to handle https://rubygems.org/gems/gem_server_conformance/ for this PR. I will do that at another pull request.

[colby-swandale]

@jenshenny before this merges, I think we need a rollout plan that accounts for a full compact index regeneration, which as far as I know hasn't happened since the initial population.

[hsbt]

Now all of related tests are fixed.