Soft limit zkApp commands per block

[Sventimir]

Explain your changes:

• This PR implements: RFC: Limit the number of zkApp commends fitting into a block. #14626.

Explain how you tested your changes:

• CI
• The graphql mutation was tested by moving the current code for the ZkApp Limit to the unauthenticated GraphQL endpoint. Here, we tested:

1. With no limit set the node behaved as usual.
2. Adding a limit via the unauthenticated GraphQL endpoint did not affect regular payments (sent through GraphQL).
3. ZkApp transactions sent via a script using o1js were capped at the ZkApp Limit.

Checklist:

• Dependency versions are unchanged
  • Notify Velocity team if dependencies must change in CI
• Modified the current draft of release notes with details on what is completed or incomplete within this project
• Document code purpose, how to use it
  • Mention expected invariants, implicit constraints
• Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• All tests pass (CI will check this if you didn't)
• Serialized types are in stable-versioned modules

[Sventimir]

!ci-build-me

[Sventimir]

!ci-build-me

[Sventimir]

!ci-build-me

[bkase]

we'll wait until discussion on the RFC settles before checking out the PR 👍

[nholland94]

As per the PR, we need some way to make this option dynamically configurable at runtime for the purposes of the authorized GraphQL server for ITN. Given that, it probably makes sense to store a ref somewhere in the application, which gets initialized the the compile time configuration at startup, and can be set dynamically during the daemon's runtime. Then the block producer code can read from that ref when it produces a block.

[Sventimir]

Thanks for your comments, @nholland94. I'll incorporate them. Please note, though, that this is still a draft. It's not yet complete or ready for review.

As to configuring the limit dynamically, I'm wary of putting refs at random places in the code. I'd much rather store it in some existing configuration struct so that it's easier to find when looked for. That's why I put it in Mina_lib.Config.t. If there's a better place, I'm happy to move it, although I think making the field mutable will be necessary, I still prefer this to a standalone ref.

[Sventimir]

!ci-build-me

[nholland94]

We should test these changes before landing this work. It doesn't seem the dynamic switching of the soft limit works as written. Also, I would like of you can address the comments I left before about the max size violation on staged ledger diff and the optional arguments.

[deepthiskumar]

!ci-build-me

[ejMina226]

!ci-build-me

[ejMina226]

!ci-build-me

[ejMina226]

!ci-build-me

[ejMina226]

!ci-build-me

[ejMina226]

!ci-build-me

[ejMina226]

!ci-build-me

[bkase]

!approved-for-mainnet

[ejMina226]

!ci-build-me