exchange: provide hint on how to disable clone bundles If a clone bundle persistently fails to apply, users need a way to disable it so they have a hope of the clone working. Change the hint for the abort scenario to advertise the config option to disable clone bundles.

exchange: document filterclonebundleentries

wireproto: properly parse false boolean args (BC) The client represents boolean arguments as '0' and '1'. bool('0') == bool('1') == True, so a simple bool(val) isn't sufficient for converting the argument back to a bool type. Currently, "obsmarkers" is the only boolean argument to getbundle. I /think/ the only place where we currently set the "obsmarkers" argument is during bundle2 pulls. As a result of this bug, the server /might/ be sending obsolete markers bundle2 part(s) to clients that don't request them. That is why I marked this BC. Surprisingly there was no test fall out from this change. I suspect a lapse in test coverage.

bundle2: gracefully skip 'obsmarkers' part if evolution is disabled We would skip the part if it was fully unknown, so we should also skip it if we know we won't be able to apply it. This will allow us to produce bundles with obsolescence markers alongside changegroup while still being able to apply them on any client.

obsstore: make the readonly attribute accessible We want to gracefully handle the read only case in some case (current target: advisory obsmarkers parts in bundle2). So we expose the attribute in a clean way.

update: introduce a 'UpdateAbort' exception The 'postincoming' function used by 'hg pull --update' and 'hg unbundle' is catching 'Abort' exceptions to intercept failed update. This feel a bit too wide to me, so I'm introducing a more precise exception to specify update destination issues.