Support etag headers

[jsnshrmn]

I believe this closes #264. This is my first time dealing with Tornado, and I was quite pleased to see that it can do most of the heavy lifting here.

I wasn't exactly sure of the client behavior we wanted to support, so I implemented it for GET and HEAD requests.

[jsnshrmn]

Note to self: check etag behavior for error responses.

[Mr0grog]

Have not tested yet (on my phone now), but this seems pretty good. Mainly nits about style.

[Mr0grog]

Oh. This should have a test!

[Mr0grog]

Also just recalled that we have utils.hash_content(content_bytes).

[jsnshrmn]

I added a super basic http get test against local files that just checks for appropriate response codes based on whether the client sends the If-None-Match header and if the value matches our computed Etag.

[jsnshrmn]

I did some manual testing of the head method, and it doesn't behave exactly has desired, since it doesn't have any of the validation that happens for get. I should either drop head, or make sure it performs enough checks to throw errors for bad requests. If we're not planning on doing head requests, I'd just drop it, but I thought I'd check the room. @Mr0grog or @danielballan?

[Mr0grog]

[A HEAD request] doesn't have any of the validation that happens for get

We didn’t support HEAD requests before (I had missed the fact that it was new when reviewing originally), so I’m not sure why we would want to add support for them in this PR. If we did (they might be nice to verify that and endpoint URL corresponds to an actual diff, but I’m not sure we have a real use-case for that, since you can also just check /), that should be a separate PR.