RadiatorDB node force removal completed

Logged when an operator force removes a configured RadiatorDB node. Removal does not wait for the remaining nodes to apply the removed node's writes and skips every configured node that does not answer a connection attempt within health_check_timeout. No other node forwards the removed node's writes, so writes that a remaining node had not applied are lost on that node. Afterwards the remaining nodes may permanently hold different data.

The node field identifies the removed node. skipped_nodes lists the configured nodes that did not answer, which can include the removed node. storage_cleared is false when the removed node was skipped, so its RadiatorDB storage stays in its database until Reprovision Node deletes it in the same Radiator Server process. remaining_nodes lists the remaining nodes that subscribed to the removed node, and diverged_nodes lists those that may hold different data. final_sync records how far each remaining node got during a short check before removal, or that its progress is unknown.

Compare the data on the nodes listed in diverged_nodes and correct any records that differ. Each remaining node in skipped_nodes keeps its subscription from and replication slot for the removed node, and the slot retains PostgreSQL WAL on that node; delete the removed node from the configuration and restart Radiator Server to remove them, as described in Force remove a node.