Linkrev perf

[Jun Wu]

Excerpts from Durham Goode's message of 2016-09-27 16:29:42 -0700:
> The map is just there to make the initial step of adjustlinkrev more 
> likely to succeed.  When it scans the changelog.i, it knows of more 
> nodes it can search for.

This may change the behavior of "_adjustlinkrev" - instead of returning the
first ancestor satisfying the condition, it may return the second, or the
third etc.

> If it finds none of those, it reverts back to the old scan-changelog.d
> behavior and fills the cache with the result.

_adjustlinkrev does not have the full view of all "introrev"s a fctx can
have, since it only walks part of the changelog graph. Therefore it only
fills part of the introrevs - the remaining are "yet to discover".

> commit, rebase, amend, etc can also be filling the cache as commits are
> added.

What if the linkrev does not need to be adjusted (i.e. it is unique)? It
seems it will fallback to the existing slow changelog walk in this case.
Since unique linkrev is not rare, so I guess this approach does not help
much.

Under the hood, I think it's the same question - cache invalidation - it's
really hard to mark "this map entry is up-to-date and all the introrevs of
the fctx is here, so slow changelog walk is unnecessary", vs. "this map
entry contains just a part of the introrevs, so you still need a slow
changelog walk".

> I'd have to think about this some more.  It sounds a little scary, and 
> I'm not sure how it would work with the wireprotocol (does the wire 
> protocol also have 12 bytes of free space?)

I didn't think too much about the wireprotocol. In the worst case, we assume
old clients by default, and translate manifest to the old format on the fly,
new clients need to explicitly tell the peer it is new.

That said, personally I also think this hash hack a bit scary, and prefer a
smaller change mentioned in:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-September/088581.html