Port more precompile tests to Rust

[ales-otf]

Description

This PR continues the work of precompile tests porting. It contains sr25519 and staking precompile tests.

Related Issue(s)

• Closes #[issue number]

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

[evgeny-s]

LGTM

I would consider keeping those TS tests in the scope of the Moonwall setup, because Rust tests ignore rate limits, and in general, this is another angle that would be great to keep. WDYT?

[open-junius]

Looks good!

[ales-otf]

LGTM

I would consider keeping those TS tests in the scope of the Moonwall setup, because Rust tests ignore rate limits, and in general, this is another angle that would be great to keep. WDYT?

Hey, thanks for reviewing! The goal is to port the contract logic tests to the rust. It doesn’t make sense to test the RPC boundary with this amount of tests. We can cover it with a few directed tests instead. For the rate limiting, it should work now, because currently our rate limiting implementation is hardcoded into the calls and spare across the codebase. But it could be the case when my PR with rate limiting was merged. But we could either setup the dispatch extension in the mock or move the test to the integration level. Additionally to the boundary thing, it’s much better to have the tests in rust instead of TS, because, well we are a team of Rust developers.