[PATCH 3 of 3 V3] memctx: allow the memlightctx thats reusing the manifest node

[Jun Wu]

Excerpts from Augie Fackler's message of 2016-11-21 18:26:16 -0500:
> Also, could histedit be updated to use this for 'mess' actions
> perhaps? Probably not easy, but if it is I'd love to see an in-tree
> client of this class. Can you take a look?

It does not work if "mess" happens after other csets creating new manifests.

Instead of making it a special for histedit. I'm always more interested in
a general purpose lower-level function doing some kind of "rebase" in core,
that smartly deals with this case and handles bookmark and dirstate parent
movements (and obsmarker creation) automatically.

There are currently multiple places reinventing the logic over and over:
  - absorb / collate
  - rebase
  - histedit
  - evolve

And once we have this API in core, we can migrate the above commands to use
it.

I'm thinking about something like:

  relocate(origctx, newparents, fileoverrides, metaoverrides, obsoleted,
           transaction)
  # origctx: context
  # newparents: [node]
  # fileoverrides: abstract dict, keys: path, value: (content, mode, renamed)
  # metaoverrides: dict with defined set of keys. to override metadata like
  #                commit message etc. 
  # obsoleted: bool, could also be a non-bool to provide more metadata

Then relocate will choose what *ctx to use internally. For absorb,
metaoverrides is empty, for metaedit, fileoverrides is empty. For rebase,
both are empty. For histedit, depends.

Two things I'd like to make sure they are considered while developing the
API:
  
  1. Giant files friendly - if we need to commit two giant files, we don't
     need to keep both of them in memory. "fileoverrides" being an abstract
     dict should solve this.
  2. Commit hooks friendly - if any commit hook is requiring a working copy,
     fallback to the slow path that writs the disk. (this could be the most
     complex part of the implementation, but I guess crecord-alike already
     has similar things). We also need to have ways to mark a commit hook as
     "do not require on-disk working copy" - could be a config option, or
     checking some magic string in the hook itself.

If we decide to go this way, I could help start some more formal discussion
(a plan page or so) - hopefully we can collect enough corner cases that
need support, have a final decision about the API soon.

CC smf because it could be related to your memctx work.