Spec should say when 'local' files are overwritten (5.1)

(I'm logging issues such as these mostly to help make the spec more precise. I hope it's useful.)

The update process described in Section 5.1 looks something like:

1. Download timestamp, verify, and compare to old timestamp.
2. If changed, download snapshot, verify, and compare to old snapshot.
3. If root metadata changed, download new, verify, and start over.
4. Download and verify other changed top-level metadata.

What does this not specify is when, say, the "old" timestamp that the client cached locally is replaced with the new timestamp from the server. This is somewhat subtle; it is not okay to replace the local copy of the timestamp with the server copy as soon as it has been verified and compared, because then we might do:

1. Download timestamp, verify, compare to local. Notice changed, replace local copy.
2. Download snapshot, verify, compare to local, notice root changed (perhaps just a new root key was added, nothing else), replace local copy.
3. Download root, verify, start process over.
4. Now we download the timestamp once again, verify it, and compare it to our local copy. Since we already replaced the local copy, we conclude it's not changed and we return "No changes" to the client.

This means we might fail to notice that there are other top-level metadata files that ought to have been replaced.

Incidentally, on a verification error in our implementation we actually delete the local timestamp and local snapshot after getting (and verifying) the new root info. We do this because, say, the timestamp key has been compromised and the attacker has set the file version to MAX_INT. Then if we don't do something to deal with this situation, clients would subsequently reject all further updates because the file version cannot change anymore. By removing the local files we basically reset the clients state to "we don't know what's on the server".

Start with Section 5.1 and trace the update sequence described in the issue, including the verification-error behavior. Clarify when locally cached timestamp and snapshot files are replaced, and ensure the reset behavior after verification errors is explicit; the section is done when these cases cannot cause missed metadata updates.