Discard cache if hash is invalid. Check response headers before caching.

[MichaelJCole]

Hi there,

This bug is related to: #84

The error symptom is:

GET http://127.0.0.1:5080/tarballs/base64id/0.1.0.tgz -> {"error":"hashes don't match, not returning"}

The expected state is:

GET http://127.0.0.1:5080/tarballs/base64id/1.0.0.tgz -> (downloads tgz)

The workaround is to delete the database and resync (lots of data and several days. Difficult to do "offline")

My best guess to a root cause is trying to use a wifi hotspot (e.g. Starbucks) before "accepting" the TOS.
When local-npm makes a request, DNS is hijacked by the router which responds with something other than the file (e.g. a login page). This "fake" version seems to be cached as local-npm continues serving this error even after the hotspot TOS is accepted. This is my best guess.

The fix would be to discard the fake cached version, so local-npm could re-GET the original.

A warning message could be shown and the response not cached if the response is missing the expected headers (see @gabrielcsapo's suggestion).

@gabrielcsapo: @MichaelJCole if you could open a new issue we can track the bug there. We would need to be able to reproduce that problem and determine if we can use headers the client sends to the server to resolve cache problems
@gabrielcsapo: @MichaelJCole this also a flaw in the caching as it does inspect the headers to validate source