[FLOC-4199] Verify that the version.html value matches the version being published

[wallrj]

Fixes: https://clusterhq.atlassian.net/browse/FLOC-4199

Sorry this branch grew so big.
I added the check for version and was faced with updating dozens of tests with fixed dictionaries of fake S3 keys.
So instead I modified FakeAWS to use an immutable FakeAWSState and added some canned states to test_release.
The tests can then transform the canned state, adding modifying keys, route and redirection rules.
Trouble is that that then broke a bunch of other test modules that also use FakeAWS so I had to go and update those too.

I also deleted a bunch of publish_docs which are concerned with publishing to a staging bucket. That is no longer part of the release process. We only ever use admin/publish_docs --production.

[wallrj]

Document error_key

[tomprince]

As indicated on the issue, we shouldn't drop support for staging, as that allows for testing the script.

[tomprince]

Looking at DownloadS3Key, it would be less code and simpler to just download to a string (which boto can do), than do some gyrations with a temporary file, just to reuse a bit of code.

[tomprince]

• Doesn't verify that code does the right thing for subdirectories
• It doesn't appear that test_overwrites_existing_documentation actually tests that anything actually overrides any content (although it is hard to be sure, since once can't tell what the test is actually testing without having several different parts of the file open at once).
• There are no running tests for deleting keys. I realize that the invalidation is broken for them, but we should still test that the part that works actually does.

As a general comment, I find the new tests harder to reason about, since I need to keep in my head what the different state constants mean as a I look at the tests. So, I don't think the less repetitive nature of the new tests is actually a good thing. Thinking about it a bit more, I wonder if having:

• a way to merge parts of buckets
• a way to generate a document tree rooted at a particular bucket prefix
  would allow the best of both worlds? That is, all the information needed to reason about a given tests in that test and not having dozens of repetitive lines in each test?

However, I think that test change is big enough to warrant separating it out from the actual functional change in this issue.