dirstate: delay writing out to ensure timestamp of each entries explicitly

Even though "dirstate.write()" is invoked explicitly after "normal"
invocations, timestamp field of entries may be still "unset" in the
"dirstate" file itself , because "pack_dirstate" drops it when it is
equal to the timestamp of "dirstate" file itself.

This can avoid overlooking modification of files, which are updated at
same time in the second. But on the other hand, this may hide timing
critical problems.

For example, incorrect "normal"-ing (or lack of "normallookup"-ing on
the already "normal"-ed entry) is visible only when:

  - the target file is modified in the working directory at T1, and
  - "dirstate" file is written out at T2 (!= T1)

Otherwise, T1 is dropped by "pack_dirstate" in "dirstate.write()"
invocation, and "unset" is stored into "dirstate" file.

It often fails to reproduce problems from incorrect "normal"-ing by
Mercurial testset, because automated actions in the small repository
almost always causes that T1 and T2 are same.

This patch adds the debug feature to delay writing out to ensure
timestamp of each entries explicitly.

This feature is used to make timing critical "dirstate" problems
reproducable in subsequent patches.

--HG--
branch : stable
largefiles: use "normallookup", if "mtime" of standin is unset

Before this patch, largefiles gotten from "other" revision (without
conflict) at "hg merge" become "clean" unexpectedly in steps below:

    1. "merge.update()" is invoked
      1-1 standinfile SF is updated in the working directory
      1-2 "dirstate" entry for SF is "normallookup"-ed

    2. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
      2-1 largefile LF (for SF) is updated in the working directory
      2-2 "dirstate" returns "n" for SF (by 1-2)
      2-3 "lfdirstate" entry for LF is "normal"-ed
      2-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
          timestamp of LF is stored into "lfdirstate" file
          (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)

Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 2-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 2-3 and 2-4) as "clean".

When timestamp is not set (= negative value) for standinfile in
"dirstate", largefile should be "normallookup"-ed regardless of
rebasing or not, because "n" state in "dirstate" doesn't ensure
"clean"-ness of a standinfile at that time.

This patch uses "normallookup" instead of "normal", if "mtime" of
standin is unset

This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, "lfdirstate" should
be updated with "dirstate" simultaneously while "merge.update"
execution: maybe by hooking "recordupdates"

It is also why this patch (temporarily) uses internal field "_map" of
"dirstate" directly.

This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 2-4)

This patch newly adds "test-largefiles-update.t", to avoid increasing
cost to run other tests for largefiles by subsequent patches
(especially, "[debug] dirstate.delaywrite" causes so).

--HG--
branch : stable
largefiles: invoke "normallookup" on "lfdirstate" for merged files

Before this patch, largefiles gotten from "other" revision (with
conflict) at "hg merge" become "clean" unexpectedly in steps below:

    1. "repo.status()" is invoked (for status check before merging)
      1-1 "dirstate" entry for standinfile SF is "normal"-ed
      1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed

    2. "merge.update()" is invoked
      2-1 SF is updated in the working directory
          (ASSUMPTION: user choice "other" at conflict)
      2-2 "dirstate" entry for SF is "merge"-ed

    3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
      3-1 largefile LF (for SF) is updated in the working directory
      3-2 "dirstate" returns "m" for SF (by 2-2)
      3-3 "lfdirstate" entry for LF is left as it is
      3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
          timestamp of LF is stored into "lfdirstate" file (by 1-2)
          (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)

Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 1-2 and 3-4) as "clean".

When state of standinfile in "dirstate" is "m", largefile should be
"normallookup"-ed.

This patch invokes "normallookup" on "lfdirstate" for merged files.

This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 3-4)

--HG--
branch : stable
largefiles: use "normallookup" on "lfdirstate" while reverting

Before this patch, largefiles gotten from revisions other than the
parent of the working directory at "hg revert" become "clean"
unexpectedly in steps below:

    1. "repo.status()" is invoked (for status check before reverting)
      1-1 "dirstate" entry for standinfile SF is "normal"-ed
     (1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed)

    2. "cmdutil.revert()" is invoked
      2-1 standinfile SF is updated in the working directory
      2-2 "dirstate" entry for SF is NOT updated

    3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()")
      3-1 largefile LF (for SF) is updated in the working directory
      3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2)
      3-3 "lfdirstate" entry for LF is "normal"-ed
      3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
          timestamp of LF is stored into "lfdirstate" file (by 3-3)
          (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)

Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 3-3 and 3-4) as "clean".

When largefiles are reverted, they should be "normallookup"-ed
forcibly.

This patch uses "normallookup" on "lfdirstate" while reverting, by
passing "True" to newly added argument "normallookup".

Forcible "normallookup"-ing is not so expensive, because list of
target largefiles is explicitly specified in this case.

This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)

--HG--
branch : stable