the previous patch broke DistributedClusteringComponentTest - which is evidently the only contrib test we have that test distributed queries.
Once i got logs enabled for the test, it was clear thatthe problem was that in the contrib test, where getSolrHome() was overridden to point to the contrib test directory with a collection1 that had all the clustering configs enabled, Solr was failing to init because there were do directories under the coreRootDirectory that both had a core.properties claiming they were collection1 ... there was the real collection1 that the test wanted, but there was also an empty cores directory that contained nothing but a core.properties file (claiming to be name=collection1.
I spent a while trying to figure out how the hell this was working before my patch, before finally giving up – because whatever it was actually doing, it seems pretty clear this was some kind of mistake – the core.properties file being created was directly in a ./cores/ directory that lookd like it was intended to be the coreRootDirectory – except the coreRootDirectory was always getting set to be the same as getSolrHome().
In any case: here's an updated patch where the (previously) odd ./cores/ directory is no longer created; the (now cloned) getSolrHome() directory is still used as the coreRootDirectory; a ./collection1/core.properties file is created if and only if it does not exist.
This fixes the problem with DistributedClusteringComponentTest in a way that also keeps my TestSimpleTrackingShardHandler working w/o modifications to either – so hopefully it should work for any end-user subclasses as well.
Still hammering on the full test suite, but i'd really appreciate it if Alan Woodward and Erick Erickson could review this since it seems like a lot of this "./cores/ dir as collection1" weirdness came about as a result of
SOLR-6840 (and perhaps SOLR-6902? ... not certain)