hgweb: filter diff hunks when 'linerange' and 'patch' are specified in filelog

hgweb: add a 'linerange' parameter to webutil.diffs() This is used to filter out hunks based on their range (with respect to 'node2' for patch.diffhunks() call, i.e. 'ctx' for webutil.diffs()). This is the simplest way to filter diff hunks, here done on server side. Later on, it might be interesting to perform this filtering on client side and expose a "toggle" action to alternate between full and filtered diff.

hgweb: handle a "linerange" request parameter in filelog command We now handle a "linerange" URL query parameter to filter filelog using a logic similar to followlines() revset. The URL syntax is: log/<rev>/<file>?linerange=<fromline>:<toline> As a result, filelog entries only consists of revision changing specified line range. The linerange information is propagated to "more"/"less" navigation links but not to numeric navigation links as this would apparently require a dedicated "revnav" class. Only update the "paper" template in this patch.

shelve: add logic to preserve active bookmarks This adds an explicit active-bookmark-handling logic to shelve. Traditional shelve handles it by transaction aborts, but it is a bit ugly and having an explicit functionality seems better.

metadataonlyctx: speed up sanity check Previously the sanity check will construct manifestctx for both p1 and p2. But it only needs the "manifest node" information, which could be read from changelog directly.

revset: factor out linerange processing into a utility function Similar processing will be done in hgweb.webutil in forthcoming changeset.

hgweb: add a "patch" query parameter to filelog command Add support for a "patch" query parameter in filelog web command similar to --patch option of `hg log` to display the diff of each changeset in the table of revisions. The diff text is displayed in a dedicated row of the table that follows the existing one for each entry and spans over all columns. Only update "paper" template in this patch.

hgweb: handle "parity" internally in webutil.diffs() There's apparently no reason to have the "parity" of diff blocks that webutil.diffs() generates coming from outside the function. So have it internally managed. We thus now pass a "web" object to webutil.diffs() to get access to both "repo" and "stripecount" attribute.

largefiles: add lfile argument to updatestandin() for efficiency (API) Before this patch, updatestandin() takes "standin" argument, and applies splitstandin() on it to pick out a path to largefile (aka "lfile" or so) from standin. But in fact, all callers already knows "lfile". In addition to it, many callers knows both "standin" and "lfile". Therefore, making updatestandin() take only one of "standin" or "lfile" is inefficient.

largefiles: use strip() instead of slicing to get rid of EOL of standin This slicing prevents from replacing SHA-1 by another (= longer hash value) in the future.

largefiles: rename local variable appropriately repo['.'] is called not as "working context" but as "parent context". In this code path, hash value of current content of file should be compared against hash value recorded in "parent context". Therefore, "wctx" may cause misunderstanding in this case.

largefiles: avoid redundant loop to eliminate None from list Before this patch, this code path contains two loops for m._files: one for replacement with standin, and another for elimination of None, which comes from previous replacement ("standin in wctx or lfdirstate[f] == 'r'" case in tostandin()). These two loops can be unified into simple one "for" loop.

largefiles: avoid meaningless changectx looking up Logically, "repo[ctx.node()]" should be equal to "ctx". In addition to it, this redundant code path is repeated "len(match.m_files)" times.

largefiles: avoid redundant changectx looking up at each repetitions These code paths look up changectx at each repetitions, even though the changectx key isn't changed while loop.

largefiles: omit updating newly added standin at linear merging Updating standin for newly added largefile is needed, only if same name largefile exists in destination context at linear merging. In such case, updated standin is used to detect divergence of largefile at overridefilemerge(). Otherwise, standin doesn't have any responsibility for its content (usually, it is empty).

largefiles: reuse hexsha1() to centralize hash calculation logic into it This patch also renames argument of hexsha1(), not only for readability ("data" isn't good name for file-like object), but also for reviewability (including hexsha1() code helps reviewers to confirm how these functions are similar). BTW, copyandhash() has also similar logic, but it can't reuse hexsha1(), because it writes read-in data into specified fileobj simultaneously.