hgext/__init__.py

lfs: explicitly add the Content-Length header when uploading blobs, for py3

This was the reason for test-lfs-test-server.t#git-server complaining about an
"invalid byte in chunk length".  For some reason if this isn't explicitly added,
py3.7.1 is adding `transfer-encoding: chunked` as well as `Content-length: x`.
Wireshark flagged this as malformed.  However, if this is set, it doesn't bother
with `transfer-encoding`.

Before this patch with py3:

  PUT /objects/31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
  Accept-Encoding: identity
  Content-length: 12
  accept: application/vnd.git-lfs
  content-type: application/octet-stream
  host: localhost:20062
  transfer-encoding: chunked
  user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-7eb7637e34bf)

Before this patch with py27:

  PUT /objects/31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1
  Accept-Encoding: identity
  accept: application/vnd.git-lfs
  content-type: application/octet-stream
  content-length: 12
  host: localhost:20062
  user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-7eb7637e34bf+20190128)

With this patch and py3, the content is the same as the py27 example.  RFC2616
says to ignore `Content-Length` if `Transfer-Encoding` is present, so maybe
there's nothing to do in the hg-server side (though I'm not sure which it is
using if presented both).

Maybe chunked encoding is better to do?  If someone knows how to suppress the
`Content-Length`, we can try that instead.

from __future__ import absolute_import
import pkgutil
__path__ = pkgutil.extend_path(__path__, __name__)