changing-files: rework the way we store changed files in side-data We need to store new data so this is a good opportunity to rework this fully. 1) We directly store the list of affected file in the side data: * This avoid having to fetch and parse the `files` list in the revision in addition to the sidedata. Making the data more self sufficient. * This work around situation where that `files` field contains wrong information, and open the way to other bug fixing (eg: issue6219) * The format (fixed initial index, sorted files) allow for fast lookup of filename within the structure. * This unify the storage of affected files and copies sources and destination, limiting the number filename stored redundantly. * This prepare for the fact we should drop the `files` as soon as we do any change affecting the revision schema. * This rely on compression to avoid a significant increase of the changelog.d. More testing on this will be done before we freeze the final format. 2) We can store additional data: * The new "merged" field, * A future "salvaged" set recording files that might have been deleted but have were still present in the final result. Differential Revision: https://phab.mercurial-scm.org/D9090

py3: use native string when comparing with a function's argspec I only found two such bugs in `contrib/perf.py` Differential Revision: https://phab.mercurial-scm.org/D9149

test: try to unflaky test-profile.t That test rely on timing measurement, because it is about timing measurement. We try to filter out the most common source of flakyness (slow disk stating)

merge: check for conflicting actions irrespective of length of bids We should for whether bids contain a combination of actions which conflict with each other. Since right now we only have couple of such combination, and combinations also consist of two actions, we were checking for them only when length of bids is 2. Let's check that irrespective of the length of bids.

branching: merge with stable

log: extract function that builds (revs, makefilematcher) from walkopts "hg grep" and "hg churn" will use this interface.

log: move --graph and topo sort options to walkopts This is the last opts.get() found in getrevs(). It might be better to define an enum, but for now, it is just a string.