Moving a page onto an existing page breaks the cache invalidation of the other cluster members

Finding from a Kubernetes test cluster, reproduced on a two-member compose cluster (remote observation enabled).

Steps to reproduce

1. On a cluster of two members, create B.Dst denying view to guests, and a public page B.Src whose parent field is already B.WebHome (so that the refactoring job does not save the moved page a second time)
2. As guest, view B.Dst on member 2 (redirected to the login page: the security cache of member 2 now holds the denial)
3. On member 1, rename B.Src onto B.Dst (the existing page is overwritten)
4. Look at the logs of member 2 and view B.Dst as guest on member 2 again

Result

For each overwritten page, member 2 logs:

ERROR DocumentEventConverter - Failed to convert remote event [... DocumentUpdatedEvent ... origdocversion=3.1 ... docname=xwiki:B.Dst}]
XWikiException: Error number 3205 in 3: Version 3.1 does not exist while reading document xwiki:B.Dst

then the event is delivered anyway with a null source and every DocumentUpdatedEvent listener fails with a NullPointerException (22 to 23 listeners per page, among them DefaultSecurityCacheRulesInvalidatorListener, GroupCacheInvalidationListener and the wiki macro and skin extension listeners). A space move overwriting 6 pages produced 6 conversion errors, about 137 "Failed to send event" errors and 143 NullPointerException stack traces on the other member.

Consequence: the caches maintained by those listeners (security rules, groups, wiki macros, skin extensions...) are not updated for the replaced page on the other members; only the document cache is invalidated. Verified with rights: after the rename, member 1 shows B.Dst to guests while member 2 still redirects them to the login page (still the case 60 seconds later), although member 2 serves the new content. The problem is hidden when the refactoring job saves the moved page once more ("Update document after refactoring.", for example when a move changes the parent field): that second DocumentUpdatedEvent converts fine and refreshes the caches.

Cause

When a document is renamed onto an existing one, XWiki#atomicRenameDocument sends a DocumentUpdatedEvent whose original document is the replaced document, after deleting that document (and its history) without event. Remote members only receive the original version number and try to load that version from the history of the reference, which now holds the history of the moved document, so the version is not found. DocumentEventConverter#fromRemote logs the error but still delivers the event without source.

Proposed fix

When the original version cannot be loaded, take the original from the recycle bin (the replaced document is there) or fall back to an empty original document, and never deliver a remote document event without source.