Normalise weights in Root Epoch Calculation

[distributedstatemachine]

Description

This PR was original created by Igor, but taking it over, as its easier to manage.

Summary:

Weights are upscaled to u16 for storage.
Therefore, weight normalization is required after weights extraction from storage.

Detailed explanation of the fix:

Without re-normalization original validator weights are being distorted by upscaling process before being applied for subnet emissions consensus.
As one of the consequences, it allows validators which set weights uniformly across subnetworks to have bigger emissions impact on subnets vs those validators who have higher variance in the weights they set.

The following example illustrates that.
Let's say:
validator 1 sets equal weights for 4 subnets: 0.25, 0.25, 0.25, 0.25 to sn1, sn2, sn3, sn4
validator 2 sets equal weights for 10 subnets: 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1 to sn 1 .. 10
validator 3 sets variable weights for 3 subnets: 0.75, 0.2, 0.05, to sn1, sn2, sn3

Max upscale to u16 makes these weight vectors to look like this in storage:
validator 1 = 65535, 65535, 65535, 65535, 0, 0, 0, 0, 0, 0, 0, …
validator 2 = 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 0, …
validator 3 = 65535, 17476, 4369, 0, 0, 0, 0, 0, 0, 0, …

Sum of the weights:
Validator 1 has the sum = 262140
Validator 2 has the sum = 655350
Validator 3 has the sum = 87380

As a result, validator weights are distorted for emissions accounting.

E.g. for subnet 2 original weights are:
from validator 1 = 0.25
from validator 2 = 0.1
from validator 3 = 0.2

But for consensus emissions calculation they are accounted as:
from validator 1 = 65535
from validator 2 = 65535
from validator 3 = 17476

It doesn't correlate with original weights.
If we assume equal stakes of these 3 validators, validator 2 with weight 0.1 was able to have 4x bigger impact on subnet 2 rank than validator 3 with weight 0.2.

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

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.