Backport #108928 to 26.6: Fix uniqExact concurrent-merge crash with GROUPING SETS/ROLLUP/CUBE

Backport #108928 to 26.5: Fix uniqExact concurrent-merge crash with GROUPING SETS/ROLLUP/CUBE

Backport #108928 to 26.4: Fix uniqExact concurrent-merge crash with GROUPING SETS/ROLLUP/CUBE

Backport #108928 to 26.3: Fix uniqExact concurrent-merge crash with GROUPING SETS/ROLLUP/CUBE

Backport #108928 to 25.8: Fix uniqExact concurrent-merge crash with GROUPING SETS/ROLLUP/CUBE

STID 1464-31ed. The two-level pointee of a UniqExactSet is shared across
several UniqExactSet objects: the merge fast path (two_level_set =
other.getTwoLevelSet()) aliases one pointee into an empty destination, and
parallelizeMergeMulti pre-fetches raw TwoLevelSet* to every state and reads
those buckets across threads. The parallel merge of ROLLUP/CUBE/GROUPING SETS
states thus reads one pointee on one thread while another thread merges into a
state that owns the same pointee.

doDeepCopyIfNeeded forked (copied the pointee before mutating) only when
shared_ptr::use_count() > 1. use_count() is not a synchronization primitive: a
sibling holder being destroyed drops the count 2 -> 1 with no happens-before
against the pointee's memory, so one state can observe use_count == 1 and write
the pointee's buckets in place while another thread is still reading the same
pointee. That is a data race (TSan reports it; issue ClickHouse#108912 was a segfault
from the same in-place write). PR ClickHouse#108928 moved the copy-on-write from the
read-intent getTwoLevelSet() to the destination path but kept the racy
use_count() guard, so the race persisted.

Attach a monotonic is_shared atomic flag to the pointee (SharedTwoLevelSet
wrapper). getTwoLevelSet() sets it (release) before the pointee escapes;
doDeepCopyIfNeeded() forks when it is set (acquire) instead of consulting
use_count(). A pointee that another thread can reach is therefore never mutated
in place; a freshly forked copy is solely owned and unshared, so the common
single-consumer case keeps mutating in place (preserving ClickHouse#108928's copy
elision).

Reproduced under TSan with a unit test that merges into and reads one shared
two-level pointee from two threads: races on the pointee buckets before the fix
(WRITE emplaceNonZeroImpl HashTable.h <- UniqExactSet::merge; READ
HashTable::size), TSan-clean after. Existing UniqExactParallelMerge gtests and
04489_uniq_exact_grouping_sets_concurrent_merge stay green, and parallel vs
single-thread GROUPING SETS results are identical.

Related: ClickHouse#108912

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

STID 1464-31ed. The two-level pointee of a UniqExactSet is shared across
several UniqExactSet objects: the merge fast path (two_level_set =
other.getTwoLevelSet()) aliases one pointee into an empty destination, and
parallelizeMergeMulti pre-fetches raw TwoLevelSet* to every state and reads
those buckets across threads. The parallel merge of ROLLUP/CUBE/GROUPING SETS
states thus reads one pointee on one thread while another thread merges into a
state that owns the same pointee.

doDeepCopyIfNeeded forked (copied the pointee before mutating) only when
shared_ptr::use_count() > 1. use_count() is not a synchronization primitive: a
sibling holder being destroyed drops the count 2 -> 1 with no happens-before
against the pointee's memory, so one state can observe use_count == 1 and write
the pointee's buckets in place while another thread is still reading the same
pointee. That is a data race (TSan reports it; issue ClickHouse#108912 was a segfault
from the same in-place write). PR ClickHouse#108928 moved the copy-on-write from the
read-intent getTwoLevelSet() to the destination path but kept the racy
use_count() guard, so the race persisted.

Attach a monotonic is_shared atomic flag to the pointee (SharedTwoLevelSet
wrapper). getTwoLevelSet() sets it (release) before the pointee escapes;
doDeepCopyIfNeeded() forks when it is set (acquire) instead of consulting
use_count(). A pointee that another thread can reach is therefore never mutated
in place; a freshly forked copy is solely owned and unshared, so the common
single-consumer case keeps mutating in place (preserving ClickHouse#108928's copy
elision).

Regression test (gtest UniqExactSharedPointeeCoW): a direct, deterministic test
of the exact lifetime transition of STID 1464-31ed. A pointee P escapes to a
second UniqExactSet via the merge fast path (use_count 2), the sibling holder is
dropped (use_count 2 -> 1), then a merge mutates the surviving state. The test
asserts the pointee address changes, i.e. the mutation forks P instead of
writing the escaped instance in place. It fails before this change (in-place
mutation, same address) and passes after it (fork, new address). A concurrent
reader cannot form a valid fails-before/passes-after gate: any holder that keeps
P alive for the reader also bumps use_count so the buggy guard forks too, while
dropping it to force use_count == 1 makes the fix free P under the reader. So
the fork-vs-in-place decision, the necessary and sufficient cause of the race,
is asserted directly. Existing UniqExactParallelMerge gtests and
04489_uniq_exact_grouping_sets_concurrent_merge stay green, and parallel vs
single-thread GROUPING SETS results are identical.

Related: ClickHouse#108912