discovery: limit 'all local heads known remotely' to real 'all' (issue4438)

3ef893520a85 made it possible that the initial head check didn't include all
heads. If that is the case, don't use the early exit just because this random
sample happened to be 'all known'.

Note: the randomness in the discovery protocol can make this problem hard to
reproduce.

--HG--
branch : stable
extra : rebase_source : 34e89b7e74cb89d95e409300cc8be68c770dce8f
discovery: indices between sample and yesno must match (issue4438)

3ef893520a85 changed 'sample' from a list to a set. The iteration order is thus
undefined and the yesno indices are not stable.

To solve this, repeat the listification and comment from elsewhere in the code.

Note: the randomness in the discovery protocol can make this problem hard to
reproduce.

--HG--
branch : stable
extra : rebase_source : a8b2c287b7ba4c623c78caf3147e0b50ad25a17d
largefiles: wrap "rebase.rebase" for functions using it directly

Before this patch, largefiles extension wraps only "rebase" in the
command table by "extensions.wrapcommand". But there are some
functions using "rebase.rebase" directly.

Without special care for them, largefiles extension can't work
correctly with such functions. In addition to it, "special care" often
becomes complicated and awkward. For example:

  - "unshelve" can't get correct result of "rebase.rebase", because of
    lack of special care

  - special care for "hg pull --rebase" causes issue3861

This patch wraps "rebase.rebase" for functions using it directly.

For simplicity, this patch keeps 'special care for "hg pull --rebase"'.
It is removed in the subsequent patch.
largefiles: remove meaningless code path for "hg pull --rebase"

This patch removes "--rebase" specific code path for "hg pull" in
"overridepull", because previous patch makes it meaningless: now,
"rebase.rebase" ("orig" invocation in this patch) can
update/commit largefiles safely without "repo._isrebasing = True".

As a side effect of removing "rebase.rebase" invocation in
"overridepull", this patch removes "nothing to rebase ..." message in
"test-largefiles.t", which is shown only when rebase extension is
enabled AFTER largefiles:

  before this patch:

    1. "dispatch" invokes "pullrebase" of rebase as "hg pull" at
       first, because rebase wraps "hg pull" later

    2. "pullrebase" invokes "overridepull" of largefiles as "orig",
       even though rebase assumes that "orig" is "pull" of commands

    3. "overridepull" executes "pull" and "rebase" directly
      3.1 "pull" pulls changesets and creates new head "X"
      3.2 "rebase" rebases current working parent "Y" on "X"

    4. "overridepull" returns to "pullrebase"

    5. "pullrebase" tries to rebase, but there is nothing to be done,
       because "Y" is already rebased on "X". then, it shows "nothing
       to rebase ..."

  after this patch:

    1. "dispatch" invokes "pullrebase" of rebase as "hg pull"

    2. "pullrebase" invokes "overridepull" of largefiles as "orig"

    3. "overridepull" executes "pull" as "orig"

    4. "overridepull" returns to "pullrebase"

    5. revision "Y" is not yet rebased, so "pullrebase" doesn't shows
       "nothing to rebase ..."

As another side effect of removing "rebase.rebase" invocation, this
patch fixes issue3861, which occurs only when rebase extension is
enabled BEFORE largefiles:

  before this patch:

    1. "dispatch" invokes "overridepull" of largefiles at first,
       because largefiles wrap "hg pull" later

    2. "overridepull" executes "pull" and "rebase" explicitly
      2.1 "pull" pulls changesets and creates new head "X"
      2.2 "rebase" rebases current working parent, but fails because
          no revision is checked out in issue3861 case

    3. "overridepull" returns to "dispatch" with exit code 1 returned
       from "rebase" at (2.2)

    4. "hg pull" terminates with exit code 1 unexpectedly

  after this patch:

    1. "dispatch" invokes "overridepull" of largefiles at first

    2. "overridepull" invokes "pullrebase" of rebase as "orig"

    3. "pullrebase" invokes "pull" as "orig"

    4. "pullrebase" invokes "rebase", and it fails

    5. "pullrebase" returns to "overridepull" with exit code 0
       (because "pullrebase" ignores result of "pull" and "rebase")

    6. "overridepull" returns to "dispatch" with exit code 0 returned
       from "rebase" at (5)

    7. "hg pull" terminates with exit code 0
largefiles: factor out procedures to update lfdirstate for post-committing

Before this patch, procedures to update lfdirstate for post-committing
are scattered in "lfilesrepo.commit". In the case of "hg commit" with
patterns for target files ("Case 2"), lfdirstate is updated BEFORE
real committing.

This patch factors out procedures to update lfdirstate for
post-committing into "lfutil.markcommitted", and makes it callable via
"markcommitted" of the context passed to "lfilesrepo.commitctx".

"markcommitted" of the context is called, only when it is committed
successfully.

Passing original "markcommitted" of the context is meaningless in this
patch, but required in subsequent one to prepare something before
invocation of it.
largefiles: factor out procedures to update standins for pre-committing

This patch factors out procedures to update standins for
pre-committing. This is one of preparations to avoid execution of such
procedures according to invocation context.

For example, resuming automated committing (e.g. "hg rebase
--continue") should update standins at the 1st commit, because
largefiles in the working directory may be modified manually. But on
the other hand, it should avoid updating standins at subsequent
committings for efficiency reason.

For simplicity, this patch just moves procedures mechanically only
with replacing below.

  - "self"            => "repo"
  - "lfutil."         => (none)
  - "orig" invocation => returning "match"

Using "fstandin" instead "standin" as the name of local variable for
the loop below is the only special care, because the latter shadows
the same name function in "lfutil.py".

  [before]
                for standin in standins:
                    lfile = lfutil.splitstandin(standin)
                    if lfdirstate[lfile] != 'r':
                        lfutil.updatestandin(self, standin)

  [after]
    for fstandin in standins:
        lfile = splitstandin(fstandin)
        if lfdirstate[lfile] != 'r':
            updatestandin(repo, fstandin)
largefiles: introduce "_lfcommithooks" to abstract pre-committing procedures

This changes allows to customize pre-committing procedures according
to conditions.

This patch uses "stack" with an element instead of flag like
"_isXXXXing" or so, because:

  - the former works correctly even when customizations are nested, and
  - ensuring at least one element can ignore empty check
largefiles: update standins only at the 1st commit of "hg rebase --continue"

Before this patch, "hg rebase --continue" may record incorrect
standins, because largefiles extension always avoid updating standins
while rebasing, even though largefiles in the working directory may be
modified manually at the 1st commit of "hg rebase --continue".

But, on the other hand, updating standins should be avoided at
subsequent commits for efficiency reason.

To update standins only at the 1st commit of "hg rebase --continue",
this patch introduces state-full callable object
"automatedcommithook", which updates standins by
"lfutil.updatestandinsbymatch()" only at the 1st commit of resuming.

Even after this patch, "repo._isrebasing = True" is still needed to
avoid some status report while updating largefiles in
"lfcommands.updatelfiles()".

This is reason why this patch omits not "repo._isrebasing = True" in
"overriderebase" but examination of "getattr(repo, "_isrebasing",
False)" in "updatestandinsbymatch".
largefiles: introduce "_lfstatuswriters" to customize status reporting

"lfutil.getstatuswriter" is the utility to get appropriate function to
write largefiles specific status out from "repo._lfstatuswriters".

This patch uses "stack" with an element instead of flag like
"_isXXXXing" or so, because:

  - the former works correctly even when customizations are nested, and
  - ensuring at least one element can ignore empty check
largefiles: get function to write status messages via "getstatuswriter()"

This patch makes "updatelfiles()" get appropriate function to write
largefiles specific status messages via "getstatuswriter()".

This patch introduces None as "print messages if needed", because True
(forcibly writing) and False (forcibly ignoring) are already used for
"printmessage" of "updatelfiles".

Subsequent patch will move "avoid printing messages only while
automated committing" decision from caller of "updatelfiles()" into
"getstatuswriter()".
largefiles: avoid printing messages while rebasing by "_lfstatuswriters"

Putting "lambda *msg, **opts: None" (= avoid printing messages always)
into "_lfstatuswriters" while rebasing makes explicit passing
"printmessage = False" for "updatelfiles()" useless.

This patch also removes setting/unsetting "repo._isrebasing" in
"overriderebase", because there is no code path referring it.
merge with stable