Summary:
Original commit: 0b5cb9c7dba5ba9987b1b4512a0156fd144524bf / D53793
Historically we have had two different functions to fetch parallel ranges from DocDB.

One worked at the time of the parallel scan structure initialization by the main backend before the workers were kicked off. At the time, the parallel scan structure was accessed by the main backend exclusively and did not require any locking. This function was responsible for fetching of the initial set of parallel ranges.

The other function was prepared to be called by a random parallel worker when the number of the parallel ranges was low. It took appropriate locks and signaled concurrent workers, so they could take the parallel ranges from the buffer and work on them while the fetch was in progress.

This diff eliminates the first function. Now the parallel scan structure is initialized empty, and is populated by the first worker ready to work. In most cases that is the main worker.

The change eliminates unnecessary complexity from the code. Early fetch of the parallel key ranges offers pretty much no benefits. Quite opposite, the delayed fetch is beneficial. If the main worker does not fetch the initial set of parallel ranges from DocDB, it can start the workers sooner. The saving is just one RPC (under 1ms in many environments), but it is not negligible if PQ is chosen by mistake or forced on a trivial scan.

Test Plan: ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressParallel#testPgRegressParallel'

Reviewers: patnaik.balivada, pjain

Reviewed By: patnaik.balivada

Subscribers: yql

Tags: #jenkins-ready

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