Improve/repair Atom feed

[tonyg]

A discussion with @florence brought to light a few issues with the current package catalog atom feed. The switch to a new UI also gives us an opportunity to consider what we want the feed(s) to contain.

Observations:

• People generally only care about a subset of packages on the server.
• Using last-updated as the change timestamp on each package's atom record becomes very noisy, since it is changed every time pkg-index rebuilds the package's hashtable (I think?).
• The atom record gives no indication of what the relevant change was.
• Sometimes authors may not intend very small updates to generate atom records. e.g. when they correct mistakes by iterative experimentation (= frequent saving) in the catalog UI.
• No way to distinguish "new package" records from "package changed" records.

Ideas:

• having a feed per package might be nice
• having a feed only of "new packages" might be nice
• having a feed of "all package updates" might be nice
• perhaps even having a feed for following new packages or all updates for a given search or tag might be nice

Please discuss and make proposals below.

[tonyg]

Thoughts on last-updated: Maybe we want to track, at a minimum, when the checksum changes, rather than anything more fine-grained than that? If I understand rightly, last-updated is quite ad-hoc at the moment.

So perhaps we could introduce a checksum-changed-timestamp field or similar that tracks when the actual package content was altered. I don't think (?) that's tracked right now.

[florence]

I'm reminded of frog's ability to generate feeds for each tag. That might be worth while.

(Then again I think if we go with multi-feed idea I will just stick to the "new packages only" feed, so my two cents probably aren't worth that much)