Add SHL, SHR and SAR shift operations for EVM v2

[ahamlat]

Description

Continues the EVM v2 implementation started in #10105.
This PR adds the SHL (0x1b), SHR (0x1c), and SAR (0x1d) shift opcodes to the EVM v2 long[]-based stack.

Changes

• Implement SHL (0x1b), SHR (0x1c), and SAR (0x1d) shift opcodes for the EVM v2 long[]-based stack, with zero heap allocation on the hot path
• Introduce StackArithmetic — a dedicated utility class for 256-bit binary and arithmetic operations operating directly on the flat long[] operand stack
• Add ShlOperationV2, ShrOperationV2, SarOperationV2 operation classes wired into the EVM v2 switch dispatch (with Constantinople gate)
• Add JMH benchmarks covering all shift execution paths: zero shift, small/medium/max shifts, overflow (>=256), sign-specific scenarios (SAR positive/negative), and fully random inputs
• Reorganize v2 operation classes under evm.v2.operation package

Benchmarks

With current main

Benchmark                                                  (caseName)  Mode  Cnt   Score   Error  Units
SarOperationOptimizedBenchmark.executeOperation               SHIFT_0  avgt   15  20.751 ± 0.233  ns/op
SarOperationOptimizedBenchmark.executeOperation      NEGATIVE_SHIFT_1  avgt   15  25.100 ± 0.224  ns/op
SarOperationOptimizedBenchmark.executeOperation      POSITIVE_SHIFT_1  avgt   15  24.940 ± 0.276  ns/op
SarOperationOptimizedBenchmark.executeOperation      ALL_BITS_SHIFT_1  avgt   15  17.057 ± 0.232  ns/op
SarOperationOptimizedBenchmark.executeOperation    NEGATIVE_SHIFT_128  avgt   15  23.680 ± 1.255  ns/op
SarOperationOptimizedBenchmark.executeOperation    NEGATIVE_SHIFT_255  avgt   15  23.860 ± 1.090  ns/op
SarOperationOptimizedBenchmark.executeOperation    POSITIVE_SHIFT_128  avgt   15  23.114 ± 0.534  ns/op
SarOperationOptimizedBenchmark.executeOperation    POSITIVE_SHIFT_255  avgt   15  22.724 ± 0.143  ns/op
SarOperationOptimizedBenchmark.executeOperation    OVERFLOW_SHIFT_256  avgt   15  23.510 ± 0.178  ns/op
SarOperationOptimizedBenchmark.executeOperation  OVERFLOW_LARGE_SHIFT  avgt   15  23.466 ± 0.186  ns/op
SarOperationOptimizedBenchmark.executeOperation           FULL_RANDOM  avgt   15  52.545 ± 0.274  ns/op

With this PR

Benchmark                                           (caseName)  Mode  Cnt   Score   Error  Units
SarOperationBenchmarkV2.executeOperation               SHIFT_0  avgt   15   6.049 ± 0.026  ns/op
SarOperationBenchmarkV2.executeOperation      NEGATIVE_SHIFT_1  avgt   15   7.862 ± 0.023  ns/op
SarOperationBenchmarkV2.executeOperation      POSITIVE_SHIFT_1  avgt   15   7.867 ± 0.069  ns/op
SarOperationBenchmarkV2.executeOperation      ALL_BITS_SHIFT_1  avgt   15   7.698 ± 0.025  ns/op
SarOperationBenchmarkV2.executeOperation    NEGATIVE_SHIFT_128  avgt   15   6.806 ± 0.018  ns/op
SarOperationBenchmarkV2.executeOperation    NEGATIVE_SHIFT_255  avgt   15   7.295 ± 0.025  ns/op
SarOperationBenchmarkV2.executeOperation    POSITIVE_SHIFT_128  avgt   15   6.821 ± 0.074  ns/op
SarOperationBenchmarkV2.executeOperation    POSITIVE_SHIFT_255  avgt   15   6.745 ± 0.019  ns/op
SarOperationBenchmarkV2.executeOperation    OVERFLOW_SHIFT_256  avgt   15   6.982 ± 0.331  ns/op
SarOperationBenchmarkV2.executeOperation  OVERFLOW_LARGE_SHIFT  avgt   15   6.974 ± 0.041  ns/op
SarOperationBenchmarkV2.executeOperation           FULL_RANDOM  avgt   15  13.682 ± 0.294  ns/op

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?

[siladu]

Should we compare benchmarks to stack_long_array as well?

[siladu]

nit: I would append V2 to the end of the filename so to keep a consistent pattern for this project, i.e. ShiftOperationsPropertyBasedTestV2.java

[siladu]

nit: I would append V2 to the end of the filename so to keep a consistent pattern for this project, i.e. getStackItemV2. Though since this is already in a V2 class, maybe could just be getStackItem here?

[siladu]

Suggested change

	private static UInt256 getV2StackItem(final MessageFrame frame, final int offset) {
	private static UInt256 getStackItem(final MessageFrame frame, final int offset) {

[parthdagia05]

@siladu
I've been implementing v2 operations under evm.operation.v2 from the original skeleton in #10105 (AND, OR, XOR, NOT in #10148, SUB, LT, GT, SLT, SGT, EQ, ISZERO in #10171). Should I move my files to evm.v2.operation to match this PR, or would you prefer to handle the migration after merge?

[siladu]

Just the V2 method name should change ideally. #10154 (comment)