The begin and end events of a remote refactoring job are handled on different threads, which breaks the observation context

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

Steps to reproduce

1. On a cluster of two members, move or rename a few pages on member 1
2. Look at the logs of member 2

Result

For each renamed page, member 2 logs one ERROR ObservationContextListener - Can't find any begin event corresponding to [org.xwiki.refactoring.event.DocumentRenamedEvent@...]. With DEBUG enabled on org.xwiki.observation.remote, 14 out of 14 DocumentRenamingEvent / DocumentRenamedEvent pairs were handled on two different JGroups receiver threads (0 on the same thread), one begin-event error per pair.

Cause

Remote events are delivered on the JGroups receiver thread pool. ObservationContextListener keeps the begin events in the ExecutionContext of the current thread, and DefaultRemoteObservationManager creates an ExecutionContext for a receiver thread the first time it needs one and never clears it. A begin event handled on thread A and its end event handled on thread B cannot be matched, and the begin event stays in thread A's context, which can later make ObservationContext#isIn answer wrongly for unrelated events handled on that thread.

Proposed fix

Deliver the remote events of one sender in order on a single thread (or with a fresh ExecutionContext per remote event, with the begin/end pairing moved to a per-sender structure), so that the observation context sees the begin and end events of a remote job the same way the local ones are seen.