archive: store number of changes since latest tag as well

This is different from latesttagdistance in that while latesttagdistance is
defined to be the length of the longest path to the latest tag,
changessincelatesttag is the number of changes contained in @ that aren't
contained in the latest tag. So, if 't' is the latest tag in the repository
below:

      t
      |
      v
 --o--o----o
    \       \
     ..o..o..@

then latesttagdistance is 2, but changessincelatesttag is 4.

Note that changessincelatesttag is always greater than or equal to the
latesttagdistance -- that's because changessincelatesttag counts all the
changes in the longest path since the latest tag, and possibly others. This is
an important fact that we'll take advantage of in upcoming patches.
setup: use changessincelatesttag from archive if present

changessincelatesttag gives one a better idea of how much the code has changed
since. Since changessincelatesttag is always greater than or equal to the
latesttagdistance (see previous patch for why), this will always produce
version numbers greater than or equal to the previous scheme.
setup: use changes since latest tag instead of just distance

For a Mercurial built on the merge from stable into default right after 3.2.2
was released -- 19ebd2f88fc7 -- the version number produced was "3.2.2+4". This
is potentially misleading, since in reality the built Mercurial includes many
more changes compared to 3.2.2.

Change the versioning scheme so that we take into consideration all the changes
present in the current revision that aren't present in the latest tag. For
19ebd2f88fc7 the new versioning scheme results in a version number of
"3.2.2+256". This gives users a much better idea of how many changes have
actually happened since the latest release.

Since changessincelatesttag is always greater than or equal to the
latesttagdistance, this will produce version numbers that are always greater
than or equal to the old scheme. Thus there's minimal compatibility risk.
pushkey: run hook after the lock release

The pushkey operation used to be in its own wireprotocol command and (in
practice) always be lock free when running the hook. With bundle2, it happen in
a greater scheme and a hook running locking command would get stuck. We now run
such hooks after the lock release as similar hook do.

Bundle2 test are altered to ensure we are lockfree at hook running time.
merge: structure 'remote created' code to match table

This does duplicate the call to _checkunknownfile(), but it will
simplify future patches.
merge: introduce 'c' action like 'g', but with additional safety

_checkunknownfile() reads the filelog of the remote side's file. For
narrow clones, the filelog will not exist for all files and we need a
way to avoid reading them. While it would be easier for the narrow
extension to just override _checkunknownfile() and make it ignore
files outside the narrow clone, it seems cleaner to have
manifestmerge() not care about filelogs (considering its
name).

In order to move the calls to _checkunknownfile() out, we need to be
able to tell in which cases we should check for unknown files. Let's
start by introducing a new action distinct from 'g' for this
purpose. Specifically, the new action will be just like 'g' except
that it will check that for conflicting unknown files first. For now,
just add the new action type and convert it to 'g'.
merge: collect checking for unknown files at end of manifestmerge()

The 'c' and 'dc' actions include creating a file on disk and we need
to check that no conflicting file exists unless force=True. Move two
of the calls to _checkunknownfile() to a single place at the end of
manifestmerge(). This removes some of the reading of filelogs from the
heart of manifestmerge() and collects it in one place close to where
its output (entries in the 'aborts' list) is used.

Note that this removes the unnecessary call to _checkunknownfile()
when force=True in one of the code paths.
merge: remove constant tuple element from 'aborts'

The second element of the tuples in the 'aborts' list is always 'ud',
so let's remove it.
merge: don't overwrite untracked file at directory rename target

When a directory was renamed and a new untracked file was added in the
new directory and the remote directory added a file by the same name
in the old directory, the local untracked file gets overwritten, as
demonstrated by the broken test case in test-rename-dir-merge.

Fix by checking for unknown files for 'dg' actions too. Since
_checkunknownfile() currently expects the same filename in both
contexts, we need to add a new parameter for the remote filename to
it.
merge: create 'cm' action for 'get or merge' case

We still have one case of a call to _checkunknownfile() in
manifestmerge(): when force=True and branchmerge=True and the remote
side has a file that the local side doesn't. This combination of
arguments is used by 'hg merge --force', but also by rebase and
unshelve. In this scenario, we try to create the file from the
contents from the remote, but if there is already a local untracked
file in place, we merge it instead.
merge: extract method for checking for conflicting untracked file

Now that the functionality is collected in one place, let's extract it
to a method.
merge: move checking of unknown files out of manifestmerge()

This moves most reading of filelogs out of manifestmerge, making it
easy for a narrow clone extension to filter out or translate unwanted
actions before any filelogs are read. The only call left is inside of
copies.mergecopies(), which can be overridden separately at a lower
level.
largefiles: ensure that the standin files are available in getlfilestoupload()

The function only adds the hash content of the file to the set to upload if the
file in the ctx is a standin.  It is called by overrides.summaryremotehook(),
which is called in the summary method.  The largefiles extension switches
'lfstatus' on in summary, so the standins shouldn't be visible when obtaining a
context there.

The reason this wasn't noticed before is that the 'lfstatus' attribute is only
being set on the unfiltered repo because of how repoview delegates attribute
assignment.  Therefore any filtered view will return a context containing
standins, whether or not 'lfstatus' was set in the various overrides methods.
That will be fixed in the next patch.  But without this change, the next patch
would have test failures for 'summary --large' stating there are no files to
upload.
largefiles: eliminate a duplicate message when removing files in verbose mode

There is no --after for addremove, so the printing for addremove can be hoisted
out of the 'not after' check.  The difference between the two remove messages
reflects the existing difference between core remove and core addremove styles
for printing the file.

There are still some pre-existing issues here.  Core addremove only prints on
inexact matches or when verbose.  But since the largefiles that are being
removed are passed to removelargefiles() as a pattern list, there is never an
inexact match, which would keep the largefiles from being printed at all unless
verbose is specified.  Therefore, the output is a little more aggressive than
core.  The addremove print style here is also inconsistent with core- it should
use matcher.uipath(f) instead of f.  These can be fixed once a matcher is passed
in.
largefiles: look at unfiltered().lfstatus to allow status() to be filtered

The comment about status being buggy with a repo proxy seems to be that status
wasn't being redirected to testing the largefiles themselves- lfstatus was
always False, and so the original status method was being called instead of
doing the largefiles processing.  This is because when the various largefile
command overrides call 'repo.lfstatus = True', __setattr__() in repoview is in
turn setting the value on the unfiltered repo, and the value in the filtered
repo remains False.

Explicitly looking at the attribute on the unfiltered repo keeps all views in
sync.