Allow knowing which cluster member must run the tasks executed only once in the cluster

Problem

In a cluster, every member runs the same background tasks at startup and periodically, although some of them work on resources shared by all the members (the database, a remote Solr server) and should run on a single member: for example the Solr index synchronization at startup, the scheduler (today disabled by hand with scheduler.enabled on all members but one, with no failover when that member is down), the extension index crawl or the recovery of pending live notification mails.

The cluster leader introduced by XWIKI-23520 goes in that direction, but a feature cannot simply ask "is this instance the one that must do it?": there is no such call, no notification when the answer changes (the leader event is not sent when an instance starts as the leader), no answer at all when remote observation is disabled, and no way to prefer a given member (for example a member dedicated to background work, which does not serve user requests).

Proposal

• A new component role ClusterSingletonManager with isSingletonNode(): true on exactly one member of the cluster, always true when remote observation is disabled or when no channel is running (single instance), and false once the instance is stopping.
• Election: among the members of the first configured channel, the member with the highest observation.remote.singletonPriority (new property, default 0) wins and ties go to the oldest member (the current channel leader). A negative priority means the member never runs these tasks. The priority travels with the network address of each member, so every member computes the same answer from the same view, without extra messages.
• A new local event ClusterSingletonNodeChangedEvent (data: true when this instance became the singleton node, false when it stopped being it), sent from a dedicated thread (never from the network thread), and one INFO log line for each change.
• A new base listener AbstractClusterSingletonListener for features that must run on the singleton node only: it does the work on its startup event if the instance is the singleton node, lets the feature catch up when the instance becomes the singleton node and stop its periodic work when it loses that role.
• NetworkMember exposes isLocal() and getSingletonPriority(), the script service exposes $services.observation.remote.singletonNode and the Observation administration section shows whether the current instance is the singleton node.
• The javadoc of NetworkChannelLeaderChangedEvent is fixed: its data is the new leader, not the previous one.

During a network partition each partition elects its own singleton node, as for the leader; the merge restores a single one.