testlists: rebuild stale user branches onto master before pushing #1244

[aagbsn]

Fixes merge conflicts on the PRs this service opens against citizenlab/test-lists (e.g. #2257: three commits from March, pushed and PR'd in August against a master that had moved on by five months of unrelated merged changes).

_pull_origin_repo()/_init_repo() already keep the shared repo's own copy of master fresh on every request. The actual bug is that a user's worktree/branch is only ever cut from master once, the first time the account starts editing (_get_user_repo()), and is never touched again no matter how far master moves before they submit.

A plain textual git rebase does not fix this for this workload: every edit here is a single-row append to a shared CSV (update()), and the busiest of these files (lists/global.csv, confirmed from the real repo's history) receive a steady stream of single-row-append commits from unrelated contributors. Two independent end-of-file insertions with nothing else in common are exactly what git's 3-way merge treats as a conflict - verified directly against real git, not a dulwich quirk - so replaying old commits onto a master with any newer, unrelated addition to the same file would still conflict, just earlier and on nearly every submission instead of rarely and on GitHub.

Instead, _rebase_user_branch_onto_master() replays the account's own tracked, structured changes (read_changes_log()/write_changes_log(), already recorded per edit) directly on top of whatever lists/.csv actually contains on master right now, then hard-resets the branch onto master and commits the result. This produces a branch that differs from master by exactly this account's pending edits and nothing else, which always applies cleanly on GitHub. It's called from _push_to_repo() right before every push.

This can raise CannotUpdateList or DuplicateURLError if replaying a change is genuinely impossible against master's current content (someone else already removed the exact row being deleted, or already added the exact URL being added) - a real conflict, not staleness. propose_changes() now re-raises any BaseOONIException from _push_to_repo() as-is instead of masking it behind the generic CannotProposeChanges, since "just retry" doesn't apply: retrying submit() alone hits the same conflict every time until the user reloads and reapplies their change. This also corrects the pre-existing uncommitted-changes-in-worktree error, which reuses CannotUpdateList, to surface as itself instead of as CannotProposeChanges.

Also fixes a latent bug in write_changes_log(): adding then deleting the same entry within one session logged a spurious delete op even though the row never reached master, which would otherwise make the replay above fail with a false "list has changed" error.

Updates test_second_users_branch_misses_first_users_merged_change (renamed to ...picks_up...) to assert the now-fixed behavior, per that test's own docstring, and updates
test_push_refuses_when_worktree_has_uncommitted_changes for the err_cannot_update_list vs err_cannot_propose_changes change above.

[aagbsn]

This should be reviewed for sanity since it's a pretty big changeset

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.18%. Comparing base (75664aa) to head (3ea611e).
⚠️ Report is 25 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1245      +/-   ##
==========================================
+ Coverage   92.42%   93.18%   +0.75%     
==========================================
  Files          86       79       -7     
  Lines        8599     7731     -868     
  Branches      509      468      -41     
==========================================
- Hits         7948     7204     -744     
+ Misses        541      437     -104     
+ Partials      110       90      -20     

Flag	Coverage Δ
ooniauth	100.00% <ø> (ø)
oonifindings	97.32% <ø> (ø)
oonimeasurements	89.61% <ø> (+0.63%)	⬆️
ooniprobe	91.30% <ø> (+0.96%)	⬆️
oonirun	98.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.