v2.0: Scheduler Frequency Fixes (backport of #4545)

[mergify]

Problem

• Scheduler is doing work in too large of chunks causing issues in block-packing

Summary of Changes

• Make the limit of transactions scanned in prio-graph does not exceed 1k
• Receive only up to 5k packets in any single call
• Hold decision behaves like the Consume decision (no timeout if non-empty)
• receive completed transactions before scheduling

Fixes #

---

This is an automatic backport of pull request #4545 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 6e93845 has failed:

On branch mergify/bp/v2.0/pr-4545
Your branch is up to date with 'origin/v2.0'.

You are currently cherry-picking commit 6e93845fb.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	both modified:   core/src/banking_stage/transaction_scheduler/prio_graph_scheduler.rs
	deleted by us:   core/src/banking_stage/transaction_scheduler/receive_and_buffer.rs
	both modified:   core/src/banking_stage/transaction_scheduler/scheduler_controller.rs

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[bw-solana]

Approving high impact back port.

Risk seems limited to handling smaller and batches at various levels of scheduling and potentially some unanticipated packing inefficiency, but there are already enough inefficiencies that there is known risk with not changing.

Changes have been de-risked by running on staked mainnet canaries and analyzing metrics during leader slots.