sslutil: some more forcebytes() on some exception messages At this point, test-https.t no longer dumps tracebacks everywhere. Instead, we get some results that look like we're not adequately finding things in hg's configuration, which should be manageable (if somewhat annoying to find and fix.) Differential Revision: https://phab.mercurial-scm.org/D2690

sslutil: sslcontext needs the cipher name as a sysstr Differential Revision: https://phab.mercurial-scm.org/D2689

sslutil: lots of unicode/bytes cleanup In general, we handle hostnames as bytes, except where Python forces them to be unicodes. This fixes all the tracebacks I was seeing in test-https.t, but there's still some ECONNRESET weirdness that I can't hunt down... Differential Revision: https://phab.mercurial-scm.org/D2687

revlog: do not use delta for lfs revisions This is similar to what we have done for changegroups. It is needed to make sure the delta application code path can assume deltas are always against vanilla (ex. non-LFS) rawtext so the next fix becomes possible. Differential Revision: https://phab.mercurial-scm.org/D2068

changegroup: do not delta lfs revisions There is no way to distinguish whether a delta base is LFS or non-LFS. If the delta is against LFS rawtext, and the client trying to apply it has the base revision stored as fulltext, the delta (aka. bundle) will fail to apply. This patch forbids using delta for LFS revisions in changegroup so bad deltas won't be transmitted. Note: this does not solve the problem entirely. It solves LFS delta applying to non-LFS base. But the other direction: non-LFS delta applying to LFS base is not solved yet. Differential Revision: https://phab.mercurial-scm.org/D2067

lfs: add a test showing bundle application could be broken When a bundle containing LFS delta uses non-LFS delta-base, or vice-versa, the bundle will fail to apply. Differential Revision: https://phab.mercurial-scm.org/D2066