tests/test-debugbundle.t

lfs: fix the stall and corruption issue when concurrently uploading blobs

We've avoided the issue up to this point by gating worker usage with an
experimental config.  See 10e62d5efa73, and the thread linked there for some of
the initial diagnosis, but essentially some data was being read from the blob
before an error occurred and `keepalive` retried, but didn't rewind the file
pointer.  So the leading data was lost from the blob on the server, and the
connection stalled, trying to send more data than available.

In trying to recreate this, I was unable to do so uploading from Windows to
CentOS 7.  But it reproduced every time going from CentOS 7 to another CentOS 7
over https.

I found recent fixes in the FaceBook repo to address this[1][2].  The commit
message for the first is:

    The KeepAlive HTTP implementation is bugged in it's retry logic, it supports
    reading from a file pointer, but doesn't support rewinding of the seek cursor
    when it performs a retry. So it can happen that an upload fails for whatever
    reason and will then 'hang' on the retry event.

    The sequence of events that get triggered are:
     - Upload file A, goes OK. Keep-Alive caches connection.
     - Upload file B, fails due to (for example) failing Keep-Alive, but LFS file
       pointer has been consumed for the upload and fd has been closed.
     - Retry for file B starts, sets the Content-Length properly to the expected
       file size, but since file pointer has been consumed no data will be uploaded,
       causing the server to wait for the uploaded data until either client or
       server reaches a timeout, making it seem as our mercurial process hangs.

    This is just a stop-gap measure to prevent this behavior from blocking Mercurial
    (LFS has retry logic). A proper solutions need to be build on top of this
    stop-gap measure: for upload from file pointers, we should support fseek() on
    the interface. Since we expect to consume the whole file always anyways, this
    should be safe. This way we can seek back to the beginning on a retry.

I ported those two patches, and it works.  But I see that `url._sendfile()` does
a rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in
one place and avoid a second seek.  We may still want the first FaceBook patch
as extra protection for this problem in general.  The other two uses of
`httpsendfile` are in the wire protocol to upload bundles, and to upload
largefiles.  Neither of these appear to use a worker, and I'm not sure why
workers seem to trigger this, or if this could have happened without a worker.

Since `httpsendfile` already has a `close()` method, that is dropped.  That
class also explicitly says there's no `__len__` attribute, so that is removed
too.  The override for `read()` is necessary to avoid the progressbar usage per
file.

[1] https://github.com/facebookexperimental/eden/commit/c350d6536d90c044c837abdd3675185644481469
[2] https://github.com/facebookexperimental/eden/commit/77f0d3fd0415e81b63e317e457af9c55c46103ee
[3] https://www.mercurial-scm.org/repo/hg/file/5.2.2/mercurial/url.py#l176

Differential Revision: https://phab.mercurial-scm.org/D7962

Create a test repository:

  $ hg init repo
  $ cd repo
  $ touch a ; hg add a ; hg ci -ma
  $ touch b ; hg add b ; hg ci -mb
  $ touch c ; hg add c ; hg ci -mc
  $ hg bundle --base 0 --rev tip bundle.hg -v --type v1
  2 changesets found
  uncompressed size of bundle content:
       332 (changelog)
       282 (manifests)
        93  b
        93  c
  $ hg bundle --base 0 --rev tip bundle2.hg -v --type none-v2
  2 changesets found
  uncompressed size of bundle content:
       344 (changelog)
       322 (manifests)
       113  b
       113  c

Terse output:

  $ hg debugbundle bundle.hg
  0e067c57feba1a5694ca4844f05588bb1bf82342
  991a3460af53952d10ec8a295d3d2cc2e5fa9690

Terse output:

  $ hg debugbundle bundle2.hg
  Stream params: {}
  changegroup -- {nbchanges: 2, version: 02} (mandatory: True)
      0e067c57feba1a5694ca4844f05588bb1bf82342
      991a3460af53952d10ec8a295d3d2cc2e5fa9690
  cache:rev-branch-cache -- {} (mandatory: False)

Quiet output

  $ hg debugbundle --quiet bundle2.hg
  Stream params: {}
  changegroup -- {nbchanges: 2, version: 02} (mandatory: True)
  cache:rev-branch-cache -- {} (mandatory: False)

Verbose output:

  $ hg debugbundle --all bundle.hg
  format: id, p1, p2, cset, delta base, len(delta)
  
  changelog
  0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a 0000000000000000000000000000000000000000 0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a 80
  991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 0000000000000000000000000000000000000000 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 80
  
  manifest
  686dbf0aeca417636fa26a9121c681eabbb15a20 8515d4bfda768e04af4c13a69a72e28c7effbea7 0000000000000000000000000000000000000000 0e067c57feba1a5694ca4844f05588bb1bf82342 8515d4bfda768e04af4c13a69a72e28c7effbea7 55
  ae25a31b30b3490a981e7b96a3238cc69583fda1 686dbf0aeca417636fa26a9121c681eabbb15a20 0000000000000000000000000000000000000000 991a3460af53952d10ec8a295d3d2cc2e5fa9690 686dbf0aeca417636fa26a9121c681eabbb15a20 55
  
  b
  b80de5d138758541c5f05265ad144ab9fa86d1db 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0e067c57feba1a5694ca4844f05588bb1bf82342 0000000000000000000000000000000000000000 0
  
  c
  b80de5d138758541c5f05265ad144ab9fa86d1db 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0000000000000000000000000000000000000000 0

  $ hg debugbundle --all bundle2.hg
  Stream params: {}
  changegroup -- {nbchanges: 2, version: 02} (mandatory: True)
      format: id, p1, p2, cset, delta base, len(delta)
  
      changelog
      0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a 0000000000000000000000000000000000000000 0e067c57feba1a5694ca4844f05588bb1bf82342 0000000000000000000000000000000000000000 66
      991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 0000000000000000000000000000000000000000 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0000000000000000000000000000000000000000 66
  
      manifest
      686dbf0aeca417636fa26a9121c681eabbb15a20 8515d4bfda768e04af4c13a69a72e28c7effbea7 0000000000000000000000000000000000000000 0e067c57feba1a5694ca4844f05588bb1bf82342 8515d4bfda768e04af4c13a69a72e28c7effbea7 55
      ae25a31b30b3490a981e7b96a3238cc69583fda1 686dbf0aeca417636fa26a9121c681eabbb15a20 0000000000000000000000000000000000000000 991a3460af53952d10ec8a295d3d2cc2e5fa9690 686dbf0aeca417636fa26a9121c681eabbb15a20 55
  
      b
      b80de5d138758541c5f05265ad144ab9fa86d1db 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0e067c57feba1a5694ca4844f05588bb1bf82342 0000000000000000000000000000000000000000 0
  
      c
      b80de5d138758541c5f05265ad144ab9fa86d1db 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0000000000000000000000000000000000000000 0
  cache:rev-branch-cache -- {} (mandatory: False)

  $ cd ..