ResponseConsumer: tolerate daft exception PotentialDataLoss

ResponseConsumer: tolerate daft exception PotentialDataLoss

The docs for this say:

  PotentialDataLoss may be raised by a transfer encoding decoder's
  noMoreData method to indicate that it cannot be determined if the
  entire response body has been delivered.  This only occurs when
  making requests to HTTP servers which do not set Content-Length or a
  Transfer-Encoding in the response because in this case the end of
  the response is indicated by the connection being closed, an event
  which may also be due to a transient network problem or other error.

[1] https://twistedmatrix.com/documents/16.6.0/api/twisted.web.http.PotentialDataLoss.html retrieved 22.8.2017

If the origin server (or proxy) chooses to use `Connection: close' and
not to provide a Content-Length, then this exception will always be
raised.  hippotatd uses Twisted's http server so does not trigger
this, but there might be an (intercepting) proxy.  If so, then
hippotat will simply not work.

Additionally, the statement in the Twisted documentation that
connection close might be due to a "transient problem or other error"
is not correct.  TCP is able to distinguish a graceful shutdown from
an ungraceful close, and origin servers ought to arrange that they do
not inappropriately perform a graceful close in error situations.

Of course a badly-implemented proxy might get this wrong, but in that
case a general web client would have no way to detect this situation
if it wants to function at all.  So certainly turning this situation
into an exception by default seems wrong.

For hippotat, ignoring the potential problem hippotat just means
potentially processing a truncated response, which might mean lost
packets (which should be retransmitted) or truncated packets (which
will be detected by the IP header length field, and retransmitted).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>