Revalidation on no match incorrectly gives back cached value, even on deleted resource

[SleeplessByte]

Related to #15

In the decision table:

rule	result
500 error	no
matches precondition	no

> Host: "https://example.org"
> Location: /my-resource
> Method: HEAD # or GET
> If-None-Match: "W/myetag"

< Host: "https://example.org"
< Location: /my-resource
< HTTP 200 Ok
< ETag: "W/newetag"

Currently it returns a 200 with the "cached" result, but actually a GET should be done to fetch the resource again. The server would return a 304 (correct in the table as well) if the preconditions match, and in that case it may use the result from the cache, but on a 200 it means that the resource has changed and should be served from the origin server.

I propose changing it to MISS. You might as well do a GET for revalidation. In case of 304, you'll get a head :not_modified, so you don't really gain anything here from doing a HEAD. Additionally, I don't the 200 status here is correct. It should report whichever status was returned from the server. Example:

> Host: "https://example.org"
> Location: /my-resource
> Method: HEAD # or GET
> If-None-Match: "W/myetag"

< Host: "https://example.org"
< Location: /my-resource
< HTTP 410 Gone

In this case on revalidation the resource has reported gone. It is correctly not a "stale-allowing-error" (your implementation of validate_is_error) and definitely not REVALIDATED. Should be MISS with the code 410. This is true for anything that's not a server error (500..599).

All of the above counts when the preconditions do not match, or are not even present in the first place (revalidation is then a simple fetch, as per #15).