chore(release): 3.91.0

What does this MR do?

chore(release): 3.91.0

3.91.0 (2024-03-25)

✨ Features ✨

• add support for Timoni image and config media types (131b5e4)
• datastore: add last_published_at timestamp to repositories table (37437f0)
• handlers: warn when online garbage collection is disabled (59dd355)

🐛 Bug Fixes 🐛

• allow OCI manifest subjects to reference non-OCI manifests (5bae10a)
• v2: oci conformance for blob upload (3a4d00b)

⚙️ Build ⚙️

• deps: update github.com/jackc/pgerrcode digest to 6e2875d (46f0e31)
• deps: update module cloud.google.com/go/storage to v1.39.0 (5fa91c7)
• deps: update module cloud.google.com/go/storage to v1.39.1 (81587b0)
• deps: update module github.com/alicebob/miniredis/v2 to v2.32.1 (40fd9e9)

Related to

Author checklist

• Feature flags
  • Added feature flag:
  • This feature does not require a feature flag
• I added unit tests or they are not required
• I added documentation (or it's not required)
• I followed code review guidelines
• I followed Go Style guidelines
• For ~database changes including schema migrations:
  • Manually run up and down migrations in a postgres.ai production database clone and post a screenshot of the result here.
  • If adding new queries, extract a query plan from postgres.ai and post the link here. If changing existing queries, also extract a query plan for the current version for comparison.
    • I do not have access to postgres.ai and have made a comment on this MR asking for these to be run on my behalf.
  • Do not include code that depends on the schema migrations in the same commit. Split the MR into two or more.
• Ensured this change is safe to deploy to individual stages in the same environment (cny -> prod). State-related changes can be troublesome due to having parts of the fleet processing (possibly related) requests in different ways.

Reviewer checklist

• Ensure the commit and MR tittle are still accurate.
• If the change contains a breaking change, apply the ~"breaking change" label.
• If the change is considered high risk, apply the label ~high-risk-change
• Identify if the change can be rolled back safely. (note: all other reasons for not being able to rollback will be sufficiently captured by major version changes).

If the MR introduces ~database schema migrations:

• Ensure the commit and MR tittle start with fix:, feat:, or perf: so that the change appears on the Changelog

If the changes cannot be rolled back follow these steps:

• If not, apply the label ~"cannot-rollback".
• Add a section to the MR description that includes the following details:
  • The reasoning behind why a release containing the presented MR can not be rolled back (e.g. schema migrations or changes to the FS structure)
  • Detailed steps to revert/disable a feature introduced by the same change where a migration cannot be rolled back. (note: ideally MRs containing schema migrations should not contain feature changes.)
  • Ensure this MR does not add code that depends on these changes that cannot be rolled back.