Fix HASKEY BigInteger index overflow

[Jim8y]

This pull request enhances the safety and correctness of array, buffer, and byte string index handling in the Neo VM by improving overflow and underflow checks and ensuring consistent type usage for indices. It also adds new test cases to verify these edge conditions.

Improvements to index validation and safety:

• Updated index validation logic in HasKey for VMArray, Buffer, and ByteString to check both lower and upper bounds using appropriate engine limits, preventing overflow and underflow errors. [1] [2]
• Standardized index handling in PickItem, SetItem, and Remove methods to use BigInteger for indices and explicitly cast to int only when accessing collections, improving type safety and clarity. [1] [2] [3] [4] [5]

Testing improvements:

• Added new test cases in HASKEY.json to verify correct FAULT behavior when array indices overflow or underflow, ensuring these edge cases are properly handled.

[shargon]

This require a Hardfork, and new Jump table

[shargon]

@Jim8y could you create the jump table in neo repository?

[roman-khimov]

Why is it better than OverflowException? Realistically proper indexes are from 0 to 2047, so any code passing MaxInt32+N is broken in about the same way code passing -1 is.

[erikzhang]

Why is it better than OverflowException? Realistically proper indexes are from 0 to 2047, so any code passing MaxInt32+N is broken in about the same way code passing -1 is.

You are right. I'll fix it.

[shargon]

Require neo-project/neo#4381

[roman-khimov]

Wish there are more tests for it (that would spot the difference in behavior), but ok logically.

[Jim8y]

Wish there are more tests for it (that would spot the difference in behavior), but ok logically.

Hi Roman @roman-khimov , do you have any idea how could we use test or anything that can formally define and verify the behavior of vm, i think it would be much better if we can use some kind of spec to formally and strictly define the behavior such that we can automatically discover any incompatiable issues if any.

[roman-khimov]

Practically current JSON-based tests are very nice to me, at least they're easy to reuse for different VM implementations. Formal spec or model is a different story.