rebase: move bookmarks with --keep (issue5682) This is a regression caused by 3b7cb3d17137. We have documented the behavior in rebase help: Rebase will destroy original commits unless you use "--keep". It will also move your bookmarks (even if you do). So let's restore the old behavior. It is done by changing `scmutil.cleanupnodes` to accept more information so a node could have different "movement destination" from "successors". It also helps simplifying the callsite as a side effect - the special bookmark movement logic in rebase is removed. Differential Revision: https://phab.mercurial-scm.org/D727

cleanupnodes: rename "mapping" to "replacements" The next patch will pass in overrides for bookmark moves, which is a mapping itself, so let's rename "mapping" to "replacements" to distinguish them better. Differential Revision: https://phab.mercurial-scm.org/D749

cleanupnodes: separate out bookmark destination calculation from actual update We will soon want to pass in overrides for bookmark movements and this will make that patch simpler. I also think this makes the code easier to follow regardless of the later patch. Differential Revision: https://phab.mercurial-scm.org/D748

ui: check for progress singleton when clearing progress bar (issue5684) A combination of wrapping `ui` and progress bars interrupted by exceptions can lead to the progress bar not being cleared when the exception error is printed. This results in corrupted-looking output like this: ``` updating [===============================> ] 1/2u nresolved conflicts (see hg resolve, then hg rebase --continue) ``` This is because in `ui._progclear`, we only check the local reference to the progress bar, not whether or not there is an instance of the singleton. When a progress bar is interrupted by an exception, the exception printing in `scmutil.callcatch` uses the original instance of the `ui` object, not the wrapped copy that has `_progbar` set. When consider whether or not to clear the progress bar, check for the existence of the singleton, rather than just whether or not we have a local reference to it. Differential Revision: https://phab.mercurial-scm.org/D743

py3: whitelist 15 more tests passing on Python 3 We have reached the count of 75 tests passing on Python 3. Differential Revision: https://phab.mercurial-scm.org/D858

py3: use pycompat.bytestr instead of str Differential Revision: https://phab.mercurial-scm.org/D855

py3: explicitly convert dict.keys() and dict.items() into a list Differential Revision: https://phab.mercurial-scm.org/D853

py3: use '%d' instead of '%s' for integers Differential Revision: https://phab.mercurial-scm.org/D856

py3: use pycompat.strkwargs() before passing a dict as keyword argument Differential Revision: https://phab.mercurial-scm.org/D854

py3: return False early while checking whether None is a key in lazymanifest In this patch we returns False early if we are trying to check whether None is a key in lazymanifest. The reason I added a diff is that on Python 3, it goes into the lazy manifest code an returns a TypeError. I checked with Durham that whether None can be a possible key in lazymanifest and he said "no". So it's safe to have this if statement. This fixes `hg merge` on Python 3. Differential Revision: https://phab.mercurial-scm.org/D852