DistributedShardedDOMDataTree service enables us to create distributed prefix-based shards. Current implementation relies on a special configuration shard where we store configuration for prefix-based shards. When we create a new distributed prefix-based shard, DistributedShardedDOMDataTree service updates this special configuration shard with new configuration and other nodes can react to this change, like create frontend for the new prefix-based shard etc.

This special configuration shard is started upon DistributedShardedDOMDataTree service start and is created on all nodes specified in module-shards.conf (e.g. module-based entity-ownership shard is started similarly). Clearly with this approach we cannot support DistributedShardedDOMDataTree service on dynamically added cluster nodes (they don't have this special configuration shard replicated).

We should not rely on static cluster nodes configuration from module-shards.conf and we should support DistributedShardedDOMDataTree service on dynamically added cluster nodes.