Feat-11 : Add limit param to stop opcode trace capture after N steps

[sagarkhandagre998]

PR description

Add limit param to stop opcode trace capture after N steps

Part of aligning Besu's debug RPC endpoints with the execution-apis spec.

What changed:

• OpCodeTracerConfigBuilder — new limit(int) config option (0 = unlimited, default)
• TransactionTraceParams — new optional limit JSON param wired into traceOptions()
• DebugOperationTracer — dedicated stepCount field drives the limit check; backfill of gasRemainingPostExecution on the last captured frame is preserved even after the limit is hit
• DebugOperationTracerTest — two new unit tests covering frame count cap and backfill correctness

Behaviour:

• When limit is absent or 0 — no change to existing behaviour
• When limit=N — exactly N StructLog entries are recorded; EVM execution continues to completion per spec

Two bugs fixed over the naive implementation:

1. Used traceFrames.size() as step counter — replaced with a dedicated stepCount field that is explicit and reset correctly per transaction
2. The last captured frame never got its gasRemainingPostExecution backfilled — moved the early-return guard in tracePostExecution to after the backfill block so it always runs

Fixed Issue(s)

Fixes #10115

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[sagarkhandagre998]

@macfarla Kindly take a look at once.

[parthdagia05]

This PR doesn't seem to handle negative limit values if someone passes limit = -1, then stepCount >= limit would be true from step 0 , so no frames would be captured. Better to reject negative values .

Also, limit = 0 is treated as "unlimited" based on the options.limit() > 0 check, but there's no test confirming that behavior. Should add one.

@sagarkhandagre998

[sagarkhandagre998]

This PR doesn't seem to handle negative limit values if someone passes limit = -1, then stepCount >= limit would be true from step 0 , so no frames would be captured. Better to reject negative values .

Also, limit = 0 is treated as "unlimited" based on the options.limit() > 0 check, but there's no test confirming that behavior. Should add one.

@sagarkhandagre998

@parthdagia05 Good Catch! will fix.