lfs: check content length after downloading content
Adapted from the Facebook repo[1]. The intent is to distinguish between the
connection dying and getting served a corrupt blob.
The original message:
HTTP makes no provision to tell your client that you failed halfway through
producing your response and won't have the answer they're looking for. So, if a
LFS server fails while producing a response, then we'll report an OID mismatch.
We can do a little better and disambiguate between "the server sent us the
wrong blob" (very scary) and "the server crashed" (merely annoying) by looking
at the content length of the response we got back. If it's not what was
advertised, we can reasonably safely assume the server crashed.
[1] https://github.com/facebookexperimental/eden/commit/
2a4a6fab4e882ed89b948bfc1e7d56d7c3c99dd2
Differential Revision: https://phab.mercurial-scm.org/D7881
wrap 0: [0, 'orig']
wrap 1: [1, 0, 'orig']
wrap 2: [2, 1, 0, 'orig']
wrap 3: [3, 2, 1, 0, 'orig']
wrap 4: [4, 3, 2, 1, 0, 'orig']
wrap 0: [0, 4, 3, 2, 1, 0, 'orig']
unwrap 3: 3: [0, 4, 2, 1, 0, 'orig']
unwrap -: 0: [4, 2, 1, 0, 'orig']
unwrap 0: 0: [4, 2, 1, 'orig']
unwrap 4: 4: [2, 1, 'orig']
unwrap 0: -: ValueError
unwrap 2: 2: [1, 'orig']
unwrap 1: 1: ['orig']
unwrap -: -: IndexError
context manager ['orig']
context manager [1, 'orig']
context manager [0, 1, 'orig']
context manager [2, 0, 1, 'orig']
context manager [2, 1, 'orig']
context manager [2, 'orig']
wrap callable object [0, 'orig']