**Describe the issue**
ClickHouse is unable to start up after upgrading from 20.8 to 21.8. 

There is a replicated table with `:` in zk path and it couldn't be loaded with:

`2021.09.15 03:49:58.435071 [ 633075 ] {} <Error> Application: DB::Exception: Unknown auxiliary ZooKeeper name '/test_prefix'. If it's required it can be added to the section <auxiliary_zookeepers> in config.xml: Cannot attach table `db1`.`table1` from metadata file /var/lib/clickhouse/metadata/db1/table1.sql from query ATTACH TABLE db1.table1 (`field1` String, `date` Date) ENGINE = ReplicatedMergeTree('/test_prefix:db1/{shard}/table1', '{replica}') PARTITION BY toMonth(date) PRIMARY KEY field1 ORDER BY field1 SETTINGS index_granularity = 8192: while loading database `db1` from path /var/lib/clickhouse/metadata/db1
`

**Expected behavior**
ClickHouse server is able to startup after upgrade without schema change. "test_prefix" in "/test_prefix:db1/{shard}/table1" is not interpreted as an auxiliary ZooKeeper name.

{
    auto zookeeper = getZooKeeper();
    Strings expected_parts_vec = zookeeper->getChildren(fs::path(replica_path) / "parts");
    
    NameSet expected_parts(expected_parts_vec.begin(), expected_parts_vec.end());
    
    auto parts = getDataParts({MergeTreeDataPartState::Committed, MergeTreeDataPartState::Outdated});
    /** Local parts that are not in ZK.
      * In very rare cases they may cover missing parts
      * and someone may think that pushing them to zookeeper is good idea.
      * But actually we can't precisely determine that ALL missing parts
      * covered by this unexpected part. So missing parts will be downloaded.
      */
    DataParts unexpected_parts;
    
    for (const auto & part : parts)
        if (!expected_parts.count(part->name))
            unexpected_parts.insert(part); 
    
    Strings parts_to_fetch;
    for (const String & missing_name : expected_parts)
        if (!getActiveContainingPart(missing_name))
            parts_to_fetch.push_back(missing_name);
    /** To check the adequacy, for the parts that are in the FS, but not in ZK, we will only consider not the most recent parts.
      * Because unexpected new parts usually arise only because they did not have time to enroll in ZK with a rough restart of the server.
      * It also occurs from deduplicated parts that did not have time to retire.
      */
    size_t unexpected_parts_nonnew = 0;