destroyed: invalidate phraserevs cache in all case (issue3858) When revisions are destroyed, the `phaserevs` cache becomes invalid in most case. This cache hold a `{rev => phase}` mapping and revision number most likely changed. Since 1c8e0d6ac3b0, we filter unknown phases' roots after changesets destruction. When some roots are filtered the `phaserevs` cache is invalidated. But not if none root where destroyed. We now invalidate the cache in all case filtered root or not. This bug was a bit tricky to reproduce as in most case we either: * rebase a set a draft changeset including root (phaserev invalidated) * strip tip-most changesets (no re-numbering of revision) Note that the invalidation of `phaserevs` are not strictly needed when only tip-most part of the history have been destroyed. But I do not expect the overhead to be significant.

largefiles: deprecate --all-largefiles for pull The same can be achieved with --lfrev pulled() and we shouldn't advertise unnecessary command line options.

largefiles: implement pull --all-largefiles as a special case of --lfrev

largefiles: drop --cache-largefiles again This goes a step further than d69585a5c5c0 and backs out the unreleased --cache-largefiles option. The same can be achieved with --lfrev heads(pulled()) and we shouldn't introduce unnecessary command line options.

largefiles: introduce pulled() revset expression for use in --lfrev This provides a general way to do what already can be done with --all-largefiles and --cache-largefiles.

largefiles: introduce pull --lfrev option The revset will be evaluated after the changesets has been pulled, and missing largefiles from matching revisions will be pulled to the local caches. This in combination with revsets will make it possible to specify different strategies for pulling largefiles. The revset expressions used for this option might be quite complex and will probably be most useful from scripts or an alias ... but less complicated than configuring hooks.

largefiles: refactor overridepull internals