sshpeer: extract the forward output logic We are about to make a more aggressive use of this when reading and writing on the other pipes. We it needs to be reusable.

sshpeer: break "OutOfBandError" feature for ssh (BC) When we'll be using the ssh's 'stderr' for realtime output successfully, it will no longer be possible to use 'stderr' to carry the error message (because it is already consumed by the real time output logic. This feature is very rarely used (test says largefile only) and I think breaking its output pattern is worth the benefit of having real time output with ssh.

error: allow a 'hint' to OutOfBandError This will be useful when changing the behavior of OutOfBandError for ssh in the next changeset.

tests: fix test-clone on vfat

wireproto: remove unused 'store' import

match: allow unioning arbitrary match functions A future patch will be allowing nested matchers. To support that, let's refactor _buildmatch to build a list of matchers then return True if any match. We were already doing that for filesets + regex patterns, but this way will be more generic.

match: add root to _buildmatch A future patch will make _buildmatch able to expand relative include patterns. Doing so will require knowing the root of the repo, so let's go ahead and pass it in.

localrepo: extract stream clone application into reusable function The existing stream_in method assumes a streaming clone is applied via the wire protocol. Previous patches have enabled streaming clone data to be produced and consumed outside the context of the wire protocol. However, the consuming part was incomplete because it didn't deal with things like updating the branch caches or writing out a requirements file. This patch finishes the separation of stream clone handling from the wire protocol. After this patch, it is possible to consume stream clones from arbitrary sources, including files. Mozilla plans to leverage this to serve pre-generated stream clone files to consumers, drastically reducing the wall and CPU time required to clone large repositories. This will enable clones to be nearly as fast as `tar`.

exchange: move code for consuming streaming clone into exchange For reasons outlined in the previous commit, we want to make the code for consuming "stream bundles" reusable. This patch extracts the code into a standalone function.

exchange: move code for generating a streaming clone into exchange Streaming clones are fast because they are essentially tar files. On mozilla-central, a streaming clone only consumes ~55s CPU time on clients as opposed to ~340s CPU time for a regular clone or gzip bundle unbundle. Mozilla is deploying static file "lookaside" support to our Mercurial server. Static bundles are pre-generated and uploaded to S3. When a clone is performed, the static file is fetched, applied, and then an incremental pull is performed. Unfortunately, on an ideal network connection this still takes as much wall and CPU time as a regular clone (although it does save significant server resources). We like the client-side wall time wins of streaming clones. But we want to leverage S3-based pre-generated files for serving the bulk of clone data. This patch moves the code for producing a "stream bundle" into its own standalone function, away from the wire protocol. This will enable stream bundle files to be produced outside the context of the wire protocol. A bikeshed on whether exchange is the best module for this function might be warranted. I selected exchange instead of changegroup because "stream bundles" aren't changegroups (yet).