memctx: remove __int__ since it is now inherited

memctx: remove __str__ since it is now inherited

memctx: call super.__init__ instead of duplicating code

memctx: inherit from committablectx This patch marks the start of having memctx inherit from committablectx, thereby making it a full-fledged context that will eventually grow the ability to perform diffing and also merging.

committablectx: fix _manifest doc string

context: fix wrong indentation from renaming method

push: use bundle2 to push phases when available We now use a bundle2 container to push all phase updates at the same time. This is a significant step forward, even if further refactoring is needed to unify phase push with the changeset push.

pushkey: add an ``encode`` function This function is just a shorthand for ``encoding.fromlocal``. It will help hiding the encoding business from other code exchanging pushkey data over the wire.

bundle2: add ``pushkey`` support After ``listkeys`` we can now include ``pushkey`` request in a bundle2. The part uses a very simple scheme closest as possible to the current wireproto command for ``pushkey``. We may eventually decide for a more sophisticated part format before the protocol becomes final.

pushkey: add a ``decode`` function This function is just a shorthand for ``decoding.fromlocal``. It will help hiding the encoding business from other code exchanging pushkey data over the wire.

pull: when remote supports it, pull phase data alongside changesets We use bundle2 to retrieve the remote phase data at the same time as changesets. This reduces the amount of requestis and should improve consistency as the server can ensure nothing changed between the retrieval of those parts.

getbundle: support of listkeys argument when bundle2 is used A new ``listkeys`` is supported by getbundle. It is a list of namespaces whose content should be included in the bundle. An appropriate entry has been added to the wireproto map of getbundle arguments and a new bundle2 capability is advertised. There are still no codes that request such parts in core mercurial.

getbundle: raise error if extra arguments are provided for bundle10 New arguments are most likely to be supported by bundle20 (and above) only.

bundle: introduce a listkey handler This makes it possible to handle listkeys-related data stored in a bundle2. There are no producers yet.

pull: split remote phases retrieval from actual application We want to be able to retrieve phases information through bundle2. The logic to apply remote phases will not change.

wireproto: use pushkey.decodekey

pushkey: introduce an ``decodekeys`` function This function provides a standardized way to exchange pushkey content over the wire.

wireproto: use pushkey.encodekey

pushkey: introduce an ``encodekeys`` function This function provides a standardized way to exchange pushkey content over the wire.

bundle2: add more phase movement in the test To test phase exchange with bundle2 we need some phase movement to happen. Appropriate logging is added to track those changes.

bundle2: use non-publishing repo in test If we are going to test usage of bundle for phases exchange, we need some phase movements to be exchanged.

bundle2: use a smarter template for test We use a more compact template that includes phase information.

getbundle: declare type of parameters In addition to listing the expected options for ``getbundle``, we also list their types and handle the encoding/decoding automatically. This should make it easier for extensions to transmit additional information to getbundle.

bundle2: introduce a ``caps20to10`` function This function factors the creation of appropriate entries to use in ``bundlecaps`` argument of ``getbundle``. This cleans up code calling ``getbundle`` and helps its usage in more part of the code.

bundle2: introduce a bundle2caps function The process of decoding remote bundle2caps blob into a dictionary is cumbersome. We move it into a small helper function. This will clarify code that reads bundle2 capabilities of peers and helps using it in new places.

exchange: reinsert comment in the right place Unrelated new code was inserted between the original comment and the related code block.

docker: check for docker.io first

buildrpm: include release version in .tar.gz name Official releases are fully indentified by the version number, these builds are not. Specs are however traditionally not versioned.

buildrpm: remove prompt for uncommitted changes - it was a bad idea We want a command that is useful in scripts, not an interactive command.

buildrpm: collect code for building local hg and using it in one place