Add tests for Polkadot runtime weights and fees

[HCastano]

This PR tackles part of #1069, specifically it will verify that the weight and fee assumption from Substrate continue to hold in Polkadot. I'd like to have tests for the Kusama and Westend runtimes as well, but depending on how big this PR gets those could be done in follow ups.

[HCastano]

I've gone through some, not all, of the crates used by the Polkadot runtime and verified that the weights of certain function are what we expect from Substrate. I didn't make the checks exhaustive, as weights will certainly change in Substrate and it doesn't seem super productive to add another place that people need to remember to update. If there are functions or pallets whose weight you think are important to verify and I've missed, also let me know.

Originally I was going to also check fees, but I'm going to split the fee checks into a different PR.

On a bit of a sidenote, I think these tests could be refactored into a macro to make the tests a little more readable. I was thinking something like:

assert_weight!(pallet, dispatchable, expected_weight);

Which would, in essence, expand to

let weight = $pallet::Call::$dispatchable::<Runtime>(...).get_dispatch_info().weight;
assert_eq!(weight, $expected_weight);

I'd need to spend a bit of time brushing up on my macro-foo to get that going, and I figured it was better to get eyes on this before going down that road.

[shawntabrizi]

a lot of these values will be changing coming up i.e. staking

[kianenigma]

Yeah, which forces me to ask: what type of breakage is this preventing?

• I like the sanity_checks_... even though the chance of breaking them is low.
• As for the rest, I think anything that breaks one of them, will break all of them, so I think only checking balance transfer is enough. Otherwise it will probably be a hard to maintain test.

[HCastano]

I disagree. Changes in one Pallet don't necessarily affect another Pallet. Tests can and should evolve over time, and I don't think these tests are particularly challenging to maintain.

I think the advantage of having these tests is that it makes sure that people realize a change happened in Substrate (by seeing a companion PR to update the tests) instead of silently having weights changed from under them.

In an extreme example, I guess we'd want to prevent something like EIP 1884, which changed the pricing of certain OPCODEs and thus some security assumptions.

[kianenigma]

instead of silently having weights changed from under them.

Makes sense.

[shawntabrizi]

This seems like a reasonable start. Want to see next an actual end to end fee calculation with a funded user.

[shawntabrizi]

if maintenance of these tests becomes too annoying because there are so many random weights, we can look to cut some down.