[DNM]Fix: no need to do the qual-clause twice

[jiaqizho]

fix #ISSUE_Number

---

Change logs

CBDB already support pushdown qual-clause. If current qual-clause have been process in access method, Then ExprState inside PlanState should reset to NULL, In this time, ExecScan should not exec it again.

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Contributor's Checklist

Here are some reminders and checklists before/when submitting your pull request, please check them:

• Make sure your Pull Request has a clear title and commit message. You can take git-commit template as a reference.
• Sign the Contributor License Agreement as prompted for your first-time contribution(One-time setup).
• Learn the coding contribution guide, including our code conventions, workflow and more.
• List your communication in the GitHub Issues or Discussions (if has or needed).
• Document changes.
• Add tests for the change
• Pass make installcheck
• Pass make -C src/test installcheck-cbdb-parallel
• Feel free to request cloudberrydb/dev team for review and approval when your PR is ready🥳

[my-ship-it]

This is my plan for heap table:

postgres=# explain analyze verbose select * from int8_tbl where q1 in (select c1 from inner_text);
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..1.05 rows=2 width=16) (actual time=2.100..2.103 rows=2 loops=1)
   Output: int8_tbl.q1, int8_tbl.q2
   ->  Seq Scan on public.int8_tbl  (cost=0.00..1.02 rows=1 width=16) (actual time=1.257..1.262 rows=2 loops=1)
         Output: int8_tbl.q1, int8_tbl.q2
         Filter: (hashed SubPlan 1)
         SubPlan 1
           ->  Broadcast Motion 3:3  (slice2; segments: 3)  (cost=0.00..150.00 rows=11600 width=32) (actual time=1.031..1.033 rows=2 loops=1)
                 Output: inner_text.c1
                 ->  Seq Scan on public.inner_text  (cost=0.00..150.00 rows=11600 width=32) (actual time=0.098..0.099 rows=1 loops=1)
                       Output: inner_text.c1
 Settings: optimizer = 'off'
 Planning Time: 0.471 ms
   (slice0)    Executor memory: 117K bytes.
   (slice1)    Executor memory: 316K bytes avg x 3x(0) workers, 414K bytes max (seg0).
   (slice2)    Executor memory: 111K bytes avg x 3x(0) workers, 111K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 2.809 ms

[my-ship-it]

So, should we handle hash Subplan correctly in Pax?

[gfphoenix78]

LGTM