Repository update races with clients

Two related issues:

1. If you don't publish the repository careful (i.e., in the same order that the spec tells you to update), you can run into lots of race conditions.
2. Even if you do publish the repository in-order and have consistent snapshots turned on, there's still a possible race if this happens halfway through the client flow.

There are a number of race conditions which can happen if the repository update is not atomic. For instance, if you publish a repository over HTTP and scp -R the files to the repository host, they might get copied in a weird order. I think this is pretty common in real deployments: the repository manipulation is done one one machine, then gets pushed to mirrors. The point of consistent snapshots, as I understand them, was to prevent this from happening, but they require that the push be done in the correct order (i.e., files are deployed in the order described in the spec).

But even if you can deploy atomically, there's still a race when timestamp keys are updated:

1. Client initiates update, grabs all the root metadata
2. Repo publishes (atomically) an updating rotating the timestamp keys, and including a timestamp with the new key.
3. Client continues with update, grabs the timestamp file, and verifying signature fails.

In general, there's pretty limited guidance in the specification here. I don't know that it's worth trying to eliminate this one race. But maybe some client guidance about retries would be helpful.

EDIT: fix a typo

Review the repository publication order, consistent snapshots, and timestamp-key client flow described in the issue. Determine whether the specification should document retries or other client handling for atomic and mid-update races; done means the relevant guidance is explicit.