narrow: add test showing that local-to-local narrow clones don't work It turns out they've never actually worked: prior to some recent refactoring they just unintentionally followed the full-clone path, which we unintentionally relied on in a test at Google. Differential Revision: https://phab.mercurial-scm.org/D4640

fastannotate: process files as they arrive peer.commandexecutor()'s context manager waits for all responses to arrive in its __exit__() method. We want to process the results as they arrive, so we should do that inside the context manager scope. Note that the futures' result() methods have been replaced to make sure that the command executor's sendcommands() method is called when the first future's result is requested, so we don't need to do that. A minor side-effect is that we can no longer easily tell when the server has started sending us responses, so that long statement was lost. Differential Revision: https://phab.mercurial-scm.org/D4666

py3: make osenvironb a proxy for, instead of a copy of os.environ where needed Without this, TESTDIR and a few other variables weren't defined in the *.t test. I didn't bother implementing all of the view functions for simplicity. All that is actually used is __{get,set}item__(), get() and pop(), but the rest seems easy enough to add for futureproofing.

memctx: simplify _manifest with new revlog nodeids This was originally written before we had modifiednodeid and addednodeid, so we had to get the parents of the context, the data from the function, and then hash that. This is much more simple now and helps refactor more code later.

context: remove unused overlayfilectx (API) It seems that this was maybe used in an extension but at this point nothing in lfs, hg-experimental, or any other cursory repo looked at has a reference to this class; so, for now, let's just remove it.

context: fix typo in workingcommitctx This was probably a copy pasta error in 745e3b485632. Refactoring memctx code exposed this bug.

filectx: fix return of renamed How is this not blowing up everywhere? It seems that filelog.renamed has always returned False (incorrectly a boolean) instead of the assumed None. Tracing through history, you need to skip over my move of code in 2013 by annotating from 896193a9cab4^ and you can see the original code is from 2007 (180a3eee4b75) and that ab9fa7a85dd9 broke this by assuming renamed was a bool (instead of None). Refactoring memctx code later exposed this bug.