How should we handle metadata that has the same version but different content? #114

The spec is a little vague as to how we should handle updating metadata that shares the same version number as the trusted metadata, but has different content. We can encounter this situation in two cases:

• When we fetch a new timestamp, section 5.2.2 says it's okay if the new file shares the same version as the trusted version. However, it doesn't say what we should do if this new file points at a different snapshot than the trusted timestamp.
• When we fetch a target or delegated target, section 4.4.4 states it's optional for the snapshot role to contain hashes of the targets and delegated targets. Without hashes, we have no way to tell without downloading the file to see if it matches the trusted version, nor what we should do if it doesn't match.

I can think of a few possible ways we could extend the spec to cover these situations:

• Just trust the new file (this though would probably expose us to all sorts of weird issues).
• Always try to download metadata, even if we think we have that version locally. Check that the new file matches our trusted content, or fail the update.
• Implement the above test for timestamp updates, but instead in section 5.4, change the logic to skip fetching any metadata version if we already trust that version (and hash if it's listed in the trusted snapshot).