revlog: rename internal functions containing "chunk" to use "segment" Currently, "chunk" is overloaded in revlog terminology to mean multiple things. One of them refers to a segment of raw data from the revlog. This commit renames various methods only used within revlog.py to have "segment" in their name instead of "chunk." While I was here, I also made the names more descriptive. e.g. "_loadchunk()" becomes "_readsegment()" because it actually does I/O.

fsmonitor: do not nuke dirstate filecache In the future, chg may prefill repo's dirstate filecache so it's valuable and should be kept. Previously we drop both filecache and property cache for dirstate during fsmonitor reposetup, this patch changes it to only drop property cache but keep the filecache.

perf: move gettimer() call This is more consistent with other perf* functions.

perf: don't clobber startrev variable Previously, the "startrev" argument would be ignored due to "startrev = 0" in the benchmark function. This meant that `hg perfrevlog` always started at revision 0. Rename the local variable to "beginrev" so the variable does the right thing.

bundle: add optional 'tagsfnodecache' data to on disk bundle (issue5543) This should help performance when unbundling.

bundle2: move tagsfnodecache generation in a generic function This will help us reusing the logic for `hg bundle`.

bundle: introduce an higher level function to write bundle on disk The current function ('writebundle') is focussing on getting an existing changegroup to disk. It is no easy ways to includes more part in the generated bundle2. So we introduce a slightly higher level function that is fed the 'outgoing' object (that defines the bundled spec) and the bundlespec parameters (to control the changegroup generation and inclusion of other parts). This is creating the third logic dedicated to create a consistent bundle2 (the other 2 are the push code and the getbundle code). We should probably reconcile them at some points but they all takes different types of input. So we need to introduce an intermediate "object" that each different input could be converted to. Such unified "bundle2 specification" could be fed to some unified code. We start by having the `hg bundle` related code on its own to helps defines its specific needs first. Once the common and specific parts of each logic will be known we can start unification.