commitctx: gather more preparation code within the lock context This is a small change that exist mostly for clarification. I am about to move a large amount of code in its own function. having all that code next to each other will make the next changeset clearer.

commitctx: move a special case about files earlier Same logic as a changeset a bit earlier, the `writefilecopymeta` section is more a post processing details so we move the conditional about `files` value closer to the rest of the code computing `files` value.

commitctx: extract all the manual logic to process the files That branch of the if is significantly more complicated than the other two. Moving it to its own function make it simple to keep the scope limited and to read to the higher level function.

commitctx: treat `filesadded` more like `filesremoved` Accumulating the filename in a list will have a negligible cost and deal with the list of added files like the other ones will make is code cleaning simpler. The two variable with very close name is not great, but my plan is to split most of the code in a separated function which will make the "problem" go away by itself.

commitctx: move `writechangesetcopy` business at the end a code section This code is to handle a specific subcase so we move it a the end. This allow to gather the rest of the "core" code closer to the related logic.

commitctx: move copy meta config reading in a dedicated function The logic is non trivial, make it contained in a function is clearer. It also unlock easy re-use of that logic without having the pass the value around.

commitctx: no longer use the `writecopiesto` variable in the function The `writefilecopymeta` variable already carry the same information, so we can use `writefilecopymeta` in the one conditional where `writecopiesto` was used.

commitctx: extract the function that commit a new manifest The logic is large enough and isolated enough to be extracted, this reduce the size of the main function, making it simpler to follow.

commitctx: stop using weakref proxy for transaction This weakref proxy was introduced in 2007 by 30d4d8985dd8. If I understand it correctly, the logic at that time was relying on the transaction destructor, triggered at garbage collection time to rollback failed transaction. passing the object to sub function directly mean it would live in the function scope and be trapped in the traceback on exception, leading to the transaction rollback too late in some case. Modern transaction usage use explicit opening and closing of transaction and no longer rely on some internal reference counting details. So this weakref proxy is no longer necessary. Absolutely no test are affected when we drop it.

rebase: fix regression in file change detection introduced by 0ecb3b11fcad Before 0ecb3b11fcad, `wctx._compact()`, was called by `wctx.nofilechanges()` as a side effect. Later, it turned out that this side effect is needed to correctly detect which files changed. See https://phab.mercurial-scm.org/D8733#131949 for the history. The problem could also be triggered by running `tests/test-rebase-parameters.t` with `--extra-config-opt rebase.experimental.inmemory=1`. Differential Revision: https://phab.mercurial-scm.org/D8843

context: re-add `overlayworkingctx._compact()` removed in 6a5dcd754842 This partially backs out 6a5dcd754842. The method was and is unused, but a call to it is introduced in the next patch. Differential Revision: https://phab.mercurial-scm.org/D8842

push: test for checks preventing publishing obsolete changeset The main difference from the previous test is how the changeset was obsoleted. In this case it is an amend so publishing the orphan would also create phase divergence. This must not go unnoticed.