Summary:
The GHI #26120 reports a correctness bug when YbBitmapIndexScan fails to update pushdown expression
upon rescan. The StorageFilter depends on a nested loop parameter, and it fails to update in time,
so the YbBitmapIndexScan runs with the "previous" filter.
This fix changes the MultiExec and ReScan handlers of the BitmapIndexScan to perform right set of
actions to ensure optimal execution in different use cases, and compatible with functions provided
by the index access method.
In particular, we create the ScanDesc only once in MultiExec. That's consistent with other index
scan implementations, so we don't waste resources if the scan is not actually executed. After that
we only update it if the scan is reset. The index_rescan is also called from the MultiExec. That
differs from the index scans implementing Next handler, because Next is normally called multiple
times after Init or between ReScan, so it is convenient to execute ScanDesc immediately after
creation, rather than to check if ScanDesc has been executed in each Next.
MultiExec is executed at most once after Init or between ReScan, hence the approach is different:
ReScan only uptates ScanDesc (that is, uptakes any parameter changes) if it exists. That way, if
ReScan is called before the first MultiExec it does bare minimum. After first MultiExec ReScan does
a bit more work to update pushdown expressions with new parameter values, but most of the work - to
drop, recreate and execute the PgGate object is done by index_rescan when, and if, MultiExec is
called.
Jira: DB-15556

Test Plan: ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressYbBitmapScans#testPgRegressYbBitmapScans'

Reviewers: telgersma, tnayak

Reviewed By: telgersma

Subscribers: yql

Tags: #jenkins-ready

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