Add RPC API for getting rate limits information

[ales-otf]

Description

This PR adds RateLimitInfoRuntimeApi, which provides RPC methods to fetch information about rate-limited transactions. The intention behind it is to allow clients to build logic not based on request errors, but by actual values.

Related Issue(s)

• Closes Add RuntimeAPI for Rate Limit Checks #892

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 cargo fmt and cargo clippy 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

[gztensor]

This design doesn't account for all of requirements:

1. As the issue described, we need to provide the rate limit information for: "submitting weights, registering networks, and staking/unstaking (among others)", not all of these are exposed

2. The following concern from the issue is not addressed either: "But this would be difficult if any changes are made on the chain-side later-on and would involve a level of coupling." We need to provide a consistent rate limit information across all rate-limited items. This is just a suggestion made for example, but it could be designed as follows:

• Requests remaining this interval
• Total requests allowed per interval
• Next interval start

Then for interval based limits like subnet registration it just fits the design and for cool-off type of limiting it can work as "remaining requests = 0" and "Next interval start = block when cool off period ends".

[gztensor]

First of all, the client software needs a way to know:

1. If it is allowed to make a request now
2. If not, then how long does it need to wait

[ales-otf]

I've found that I forgot to add NetworkRateLimit, BTW.

As I saw it, the problem is that when you deal with limits you get the error and you need to figure out whether you are allowed to perform the request without getting error - without performing an actual transaction.

"submitting weights":

There is already API for getting weight limits: SubnetInfoRuntimeApi::get_subnet_hyperparams:

• min_allowed_weights
• max_weights_limit
• weights_rate_limit

"registering networks":

Regarding subnet registrations per block: SubnetInfoRuntimeApi::get_subnet_hyperparams::max_regs_per_block.

Couldn't find anything more related to network registration rate limits.

Staking/unstaking covered by two methods: RateLimitInfoRuntimeApi::get_rate_limits and
RateLimitInfoRuntimeApi::get_stakes_this_interval.

If the clients want to check whether they exceeded the quota, they check the number of stakes allowed during interval stakes and compare it to the stakes made during interval.

We can't cover all the cases and logic, but given this data clients can build the logic, which prevent from executing transactions.

[sam0x17]

bit late to this but idea: what if we just provide rate limiting information in the responses to all rate-limited requests. Like tell them how close to the quota they are at all times. Then we won't have extra traffic of them constantly checking these rpcs