[Feature Request] Use unified registry center client for different scenarios in proxy

Some discussion notes with @terrymanu . It's related to ElasticJob and ShardingSphere Proxy Mode.

Currently, registry center client will be created, all of them use configuration from mode in server.yaml:
- ModeScheduleContext.initRegistryCenter, create org.apache.shardingsphere.elasticjob.reg.base.CoordinatorRegistryCenter. Which is used by db-discovery rule.
- CoordinatorRegistryCenterInitializer.createRegistryCenter, create org.apache.shardingsphere.elasticjob.reg.base.CoordinatorRegistryCenter. Which is used by scaling.
- ClusterPersistRepositoryFactory.getInstance, create org.apache.shardingsphere.mode.repository.cluster.ClusterPersistRepository. Which is used by proxy.

It means it might create 3 ZooKeeper client if mode Cluster type is ZooKeeper.

Why there're several registry center client?
1. `org.apache.shardingsphere.elasticjob.reg.base.CoordinatorRegistryCenter` is different with `org.apache.shardingsphere.mode.repository.cluster.ClusterPersistRepository`, seems could not be wrappered simply.
2. Since modules dependency hierarchy, `ModeScheduleContext` could not reuse `CoordinatorRegistryCenterInitializer`.

```
data-pipeline-core (includes CoordinatorRegistryCenterInitializer)
mode-core (CoordinatorRegistryCenterInitializer depends on it)
schedule-core (includes ModeScheduleContext)
```

It's better to use unified registry center client, just reuse the proxy one.

Start by tracing ModeScheduleContext.initRegistryCenter, CoordinatorRegistryCenterInitializer.createRegistryCenter, and ClusterPersistRepositoryFactory.getInstance across the listed module dependency hierarchy. Compare the three registry-client creation paths and determine how the proxy repository can be reused without violating those dependencies. Done means the relevant proxy, scaling, and database-discovery scenarios use one registry center client instead of creating three ZooKeeper clients.

Written by the indexing model from the issue text.