Use alpha for stake in neuron info

[ales-otf]

Description

This PR fixes inconsistency issues related to staking values returned by RPC's NeuronInfoRuntimeApi and StakeInfoRuntimeApi.

Getters for the stake values are added to NeuronInfo, NeuronInfoLite and StakeInfo, because there is no other way to test this values in the integration tests.

Related Issue(s)

• Closes Inconsistent stake numbers across RPCs #879

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):

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

Additional Notes

It would be better to introduce different types for TAO and Alpha balances, so these kinds of errors would be discoverable at the compilation time (#887).

Also, to prevent possible inconsistencies between NeuronInfo and NeuronInfoLite it would be better to make NeuronInfoLite a part of NeuronInfo, instead of duplicating information between them.

Allowing unit/module tests would help with private API testing. In case the module tests are not possible, another option could be a cargo feature, which would make API dedicated to tests being compiled for tests only (#[cfg(test)] doesn't work for the integration tests).

[camfairchild]

The reason we use stake_weight is because this is what miners need to prioritize Validator requests appropriately.
This value directly impacts a miner's emission, versus the alpha entry, which is not meaningful.

[ales-otf]

The reason we use stake_weight is because this is what miners need to prioritize Validator requests appropriately. This value directly impacts a miner's emission, versus the alpha entry, which is not meaningful.

But in NeuronInfoLite the value was from Stake storage, while in NeuronInfo from StakeWeight, and in StakeInfo it's Alpha. Which one is true then?

Or is it StakeWeight only in NeuronInfo?

[ales-otf]

The reason we use stake_weight is because this is what miners need to prioritize Validator requests appropriately. This value directly impacts a miner's emission, versus the alpha entry, which is not meaningful.

Can we add additional field stake_weight to NeuronInfo and NeuronInfoLite? Also, if we can, could we make NeuronInfoLite being a part of NeuronInfo to omit the duplication and inconsistencies?

[camfairchild]

The reason we use stake_weight is because this is what miners need to prioritize Validator requests appropriately. This value directly impacts a miner's emission, versus the alpha entry, which is not meaningful.

But in NeuronInfoLite the value was from Stake storage, while in NeuronInfo from StakeWeight, and in StakeInfo it's Alpha. Which one is true then?

Or is it StakeWeight only in NeuronInfo?

I believe this change is attempting to keep the same struct type-wise, while changing the value to be as meaningful to the client as it was.

When we didn't have the Alpha map, the only value that mattered in this context was the Stake map. But now we use a calculated stake_weight to mean the same thing. So this is what should be returned

[camfairchild]

Can we add additional field stake_weight to NeuronInfo and NeuronInfoLite?

We could, but the big issue with this is we don't have proper versioning set up for the RuntimeAPIs and RPCs. So this will break any clients that rely on this API (many).

[gztensor]

@camfairchild , we have get_global_for_hotkey_and_coldkey and get_global_for_hotkey_and_coldey_on_subnet methods. Can we just use them in StakeInfo and NeuronInfo respectively?

[ales-otf]

Closing, as NeuronInfo::stake should be StakeWeight and the difference between StakeInfo::stake and NeuronInfo::stake is expected and should be handled on the client's side.

To fix the inconsistency between NeuronInfo::stake and NeuronInfoLite::stake a separate PR is open.