Split compute budget instructions process from struct itself

[tao-stones]

Problem

struct ComputeBudget is to be passed to vm for tracking compute unit consumption, but it's process_instructions(...) are being used elsewhere, unrelate to vm, to parse and get limits compute_budget_instructions set.

the instruction processing function can/should be separated from the struct that holds budget limits. This would clean up logic, is a precursor step for RuntimeTransaction at #33471

Summary of Changes

• split instructions processing function into its own module,
• restore ComputeBudget to be pure structure that is passed via invoke_context.

Fixes #

[codecov]

Codecov Report

Merging #33513 (297353f) into master (7aa0fae) will increase coverage by 0.0%.
Report is 3 commits behind head on master.
The diff coverage is 93.5%.

@@           Coverage Diff           @@
##           master   #33513   +/-   ##
=======================================
  Coverage    81.8%    81.8%           
=======================================
  Files         806      807    +1     
  Lines      217937   217907   -30     
=======================================
- Hits       178322   178318    -4     
+ Misses      39615    39589   -26     

[tao-stones]

No functional change, a lot tests updates tho

[apfitzge]

Left a few comments. I think this is the right direction, we want to separate the initial processing from ComputeBudget so we can do this processing early on and carry the result until we need to construct a ComputeBudget

[apfitzge]

Most of the diff comes from moved code and tests being changed.
I'm much happier with this than the current state of things; it will make it significantly easier to create a RuntimeTransaction type that holds additional meta data to avoid unneccessary re-processing.

[alessandrod]

Looks good, just a couple of minor nits

[mergify]

automerge label removed due to a CI failure

[steviez]

Just a heads up that this commit is going to get reverted from master. One of the canaries running tip-of-master diverged from consensus, and I narrowed the divergence down to this commit. See #33784 for more details, especially #33784 (comment)

[tao-stones]

Just a heads up that this commit is going to get reverted from master. One of the canaries running tip-of-master diverged from consensus, and I narrowed the divergence down to this commit. See #33784 for more details, especially #33784 (comment)

Thanks for heads up, Looking into the cause ...

[ilya-bobyr]

Do we consider solana_program_runtime part of the public API?
If so, this change is not backward compatible.

[tao-stones]

Do we consider solana_program_runtime part of the public API? If so, this change is not backward compatible.

It shouldn't be public api. (https://discord.com/channels/428295358100013066/439194979856809985/1166387183389782167)