…n is re-planned

With parallel_replicas_min_number_of_rows_per_replica above 0 an `IN` subquery was
planned, index-analyzed and executed twice. Measured on a 100,000-row MergeTree with
`SELECT sum(key) FROM t WHERE key IN (SELECT key FROM t WHERE key > 50000)`: read_rows
100,000 -> 150,000 (1.50x) and IndexAnalysisRounds 2 -> 3, with correct results. Under
distributed_index_analysis each extra analysis is also a cross-replica round trip,
which is what 04052_distributed_index_analysis_in_subquery_no_quadratic counts.

The chain. Above 0 the setting makes collectFiltersForAnalysis build a throwaway
StorageDummy plan purely to harvest filter DAGs for the row-count estimate. The
estimate's index analysis (selectRangesToRead -> KeyCondition::tryPrepareSetIndexForIn
-> buildOrderedSetInplace) fills the `IN` set behind that DAG, and the DAG reaches the
executed read as SelectQueryInfo::filter_actions_dag: ActionsDAG::clone copies
Node::column by pointer, so the executed read's filter surface holds the same,
already-filled set object. createLocalPlanForParallelReplicas then re-plans the local
replica's query from the query tree with a fresh PlannerContext and a fresh, empty set,
so the first KeyCondition built over the local plan's `key IN <empty set>` fills it a
second time. The outer read is spared because its analysis is transplanted; a read
nested under an `IN` is not.

Measurement decided which surface to collect from. Of the analyzed read's four
candidate filter surfaces only getQueryInfo().filter_actions_dag ever carries the
filled set, both with prewhere at its defaults and with optimize_move_to_prewhere and
query_plan_optimize_prewhere off; getFilterActionsDAG(), the prewhere actions and the
row-level filter are null in every configuration measured. The collector is therefore
called on that one surface instead of on all four.

createRemotePlanForParallelReplicas and createRemotePlanFragmentForParallelReplicas are
deliberately left alone: those plans are serialized and shipped, an in-memory Set
cannot travel, and each replica must build its own.

The external-table guard sits in the new collector rather than in reuseBuiltSets or
collectBuiltSets because the difference is in the consumer, not in the mechanism. The
existing collectBuiltSets deliberately shares GLOBAL IN sets: its only consumer is the
automatic-parallel-replicas probe plan, which is never executed, and 03800's query_6
measures that behaviour. This consumer is executed, so it declines any set whose fill is
entangled with an external table. That is a conservative boundary rather than a defect
being fixed: on this path buildQueryTreeForShard materializes a GLOBAL IN subquery into
the temporary table before the local plan exists and replaces the subquery with a read of
that table, so the re-planned set is keyed on the table and cannot match an offered set
anyway. The hash collision the predicate rules out is real - the collected GLOBAL IN set's
hash is byte-identical to a plain IN's over the same subquery text, because the set is
registered before that substitution - and refusing it keeps reuseBuiltSets,
collectBuiltSets and the probe path byte-for-byte unchanged.

Pruning is preserved rather than degraded. Both in-place build paths fill the set's
elements, so an adopted set reports hasExplicitSetElements() and the local plan's own
KeyCondition still uses the index instead of falling back to a set-less condition.

At the default 0 there is no pre-pass, the filter surface is null, nothing is collected
and reuseBuiltSets returns at its first statement, so those plans are unchanged. No
setting is added, changed or re-defaulted.

This closes the parallel_replicas_min_number_of_rows_per_replica trigger. It does not
close the parallel_replicas_plan_based = 1 trigger of ClickHouse#118275: that path splits one
plan into fragments rather than re-planning it, it doubles both analyses rather than
one, and 04052 under it behaves identically before and after this change.

Related: ClickHouse#118275