updateinfo: Prefix the file name with its hash

This is similar to what is done with other Yum repository metadata.

It is not just about consistency though, it fixes real issues.

For example, at work, we use the Amazon CDN to implement mirroring of
our Yum repositories. All files are cached on the CDN for the default
duration (i think it's 24 hours), except repomd.xml which is never
cached.

This works great for RPMS (they never change once published) and all
the metadata files (their names are prefixed with their hash, and as
such the CDN sees them as different files).

However, we keep running into trouble with updateinfo.xml.gz: the CDN
keeps distributing the old file even though a new one was generated.

Because the updateinfo metadata can be quite big, we'd rather prefix
its name with a hash (like other Yum repository metadata), and let the
CDN handle it, rather than telling the CDN to never cache it, which
would put more load on our primary repository server.
updateinfo: While we're at it, move to sha256

All other Yum repository metadata are already using this stronger hash,
so let's be consistent and more secure.
updateinfo: Remove misleading comments

If someone tries to uncomment these for debugging purpose, they might
not realize that they don't reflect reality any more, and might waste
lots of time trying to figure out what is going on.
updateinfo: Remove previous cached updateinfo

Now that we prefix the file name with its hash, each written file will
have a different name.

As a result, we need to remove the previous versions when we load it,
otherwise we end up accumulating updateinfo.xml.gz metadata files.
Fix changelog handling

The RPM API does not seem to always return a list for the changelog
timestamp(s).

Bodhi has some code trying to identify that and treat it accordingly.

However, it was based on the identified cases where this happened (there
is only one changelog text) instead of just being based on whether or
not the changelog was a list.

It seems that this behaviour in the RPM Python API, as I'm now seeing
cases where Bodhi thinks the timestamp is not in a list, when it
actually is.

This commit fixes this.
masher: Find the old updateinfo files

Now that we prefix the updateinfo metadata with its hash, the Bodhi
masher must be taught to find it.

The bonus point of using a glob is that it even handles migration from
non-prefixed to prefixed file name. :)
tests: Teach the metadata tests about the new updateinfo name
tests: Add a message on the assertion error

This assertion was failing due to a syntax error in my masher/updateinfo
code.

Adding this message allowed me to find it quickly, and it could be
useful in the future.
Merge pull request #38 from bochecha/changelog

Fix changelog handling
Merge pull request #35 from bochecha/updateinfo

Prefix the updateinfo file with its hash