Summary:
Original commit: 4fba06e00345503b0d1c92c4fc99c192f9c07963 / D55825
The unsynchronized access to the YBParallelPartitionKeys structure by
the ybParallelPrepare function was based on the comment, where it was
claimed that the worker has the structure exclusively at the time of
the initialization. That statement was probably outdated, and apparently
false. In reality, each parallel workers calls ybParallelPrepare to make
sure the structure is initialized, as the ybParallelPrepare is
idempotent by design. The idempotency feature worked properly in most
scans, because the main worker usually attempts to initialize the
structure first, before the background workers are ready. When
background workers call ybParallelPrepare, the structure is already
initialized and ybParallelPrepare does nothing.

However, in the repro script published in #32509 the main worker
participation is disabled, and the parallel workers are simultaneously
call ybParallelPrepare. Hence there's a higher chance that two of them
see uninitialized structure and proceed with initialization. Both of
them populate target relation data and direction, that part is fine,
both write down the same data. But then each of them adds starter empty
key to the buffer. The consequence of having two empty keys in the
buffer is double scan: the range between empty key and empty key is
whole table. After that, there go regular parallel ranges, and parallel
scan is performed as it is supposed to, one more time. That's why the
problem manifests as double aggregate numbers.

This diff:
- Updates the comments on ybParallelPrepare
- Adds proper mutex syncronization to ybParallelPrepare
- Removes unused exec_params parameter.

Backport-through: 2025.2

Test Plan:
Retest the repro.
Error rate is too low to add to unit/regression tests.

Reviewers: patnaik.balivada, pjain

Reviewed By: patnaik.balivada

Subscribers: yql

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D55932