private static List<Node> toNodes(String clusterName, DispatchNodesConfig nodesConfig) {
        return nodesConfig.node().stream()
                .map(n -> new Node(clusterName, n.key(), n.host(), n.group()))
                .toList();
    }
This is called whenever we have new config for backend nodes.
Normally, we'd want to handle partial failure of the component graph, by reinstating the old state;
however, in this case, such a failure would be local to this container, and we instead want to keep
the newest config, as that is what most accurately represents the actual backend.

The flow of reconfiguration is:
1. The volatile snapshot of disposable items is replaced with a new one that only references updated nodes.
2. Dependencies of the items in 1., which must be configured, are updated, yielding a list of resources to close.
3. When inflight operations against the old snapshot are done, all obsolete resources are cleaned up.

Ownership details:
1. The RPC resource pool is owned by the dispatcher, and is updated on node set changes;
   it contains the means by which the container talks to backend nodes, so cleanup must be delayed until safe.
2. The invocation factory is owned by the volatile snapshot, and is swapped atomically with it;
   it is used by the dispatcher to create ephemeral invokers, which must complete before cleanup (above) can happen.
3. The load balancer is owned by the volatile snapshot, and is swapped atomically with it;
   it is used internally by the dispatcher to select search nodes for queries, and is discarded with its snapshot.
4. The cluster monitor is a subordinate to the search cluster, and does whatever that tells it to, at any time;
   it is technically owned by the dispatcher, but in updated by the search cluster, when that is updated.
5. The search cluster is owned by the dispatcher, and is updated on node set changes;
   its responsibility is to keep track of the state of the backend, and to provide a view of it to the dispatcher,
   as well as keep the container vip status updated accordingly; it should therefore preserve as much as possible
   of its state across reconfigurations: with new node config, it will immediately forget obsolete nodes, and set
   coverage information as if the new nodes have zero documents, before even checking their status; this is fine
   under the assumption that this is the common case, i.e., new nodes have no documents yet.
container-search/src/main/java/com/yahoo/search/dispatch/Dispatcher.java