Problem Validation: What other information is useful in the dependency proxy UI

Context

In #250865 (closed), we proposed adding a list of image tags that have been cached using the dependency proxy. This is a helpful MVC, but there are several open questions about what comes next. For example:

Questions I'd like to explore:

• how relevant showing how "fresh" an item is in the cache?
• what are reasons they are viewing the Dependency Proxy UI?
• what information is missing? (e.g. manifests and blobs..)
• what is their understanding of how the TTL works? I keep forgetting that the 90 day time resets when accessed.
• what do they need to see: read_at, created_at, or both? Why?

Proposal

Put together a discussion guide and interview users of the dependency proxy to answer the above questions and use that research to fuel a new design/feature for the dependency proxy.

Hypothesis

• People visiting the UI will be double-checking that something they recently published is in the cache.
• People visiting the UI will be browsing what's in there.
• The best way to order the list of tags in the UI is by most recent activity.
• As long as users are not having problems with rate limiting or slow builds they don't need to how long the tag has left in the cache

Option 1: We don't know enough about why our users view the UI so we remove the field(s) from the UI for now

Option 2: We show the most recent activity in this field conditionally.
If the tag was just published, the UI says "Cached at" with the created_at attribute.
If the tag was just accessed the UI says "Accessed at" or "Read at" using the read_at attribute

Option 3: we show both the created_at and read_at in the UI.