Refactor weight constants, Update to remove redundant overhead

[shawntabrizi]

This PR moves some of the FRAME specific weight constants (DbWeight, ExtrinsicBaseWeight, BlockExecutionWeight) to the frame-support library. Since we already make heavy assumptions about how to derive these weights based on our specific setup of FRAME, it makes sense to move these thing into there.

Additionally, this updates some weight values across various extrinsic to make them even a bit more lightweight!

We found that we had double counted the overhead implied by a Heavy DB by testing our DB Trie stats with a full DB and also testing our runtime with a full chain spec. The full chain spec in the runtime was not needed since we assume now every DB read will be ~200K item (5 trie look ups) heavy.

As a result, we get some lower weights!

This updates:

• Balances
• Vesting
• Utility

TODO in another PR: Update all weights to use these consts

[kianenigma]

probably will need a companion as well.

[gavofyork]

apparently not.

[shawntabrizi]

@gavofyork will make a similar change to polkadot, but ya, this merging wont break anything

[JoshOrndorff]

@shawntabrizi I know this is old, but I have a question.

Moving the ExtrinsicBaseWeight to frame support implies (to me at least) that it should be re-useable across chains. But doesn't it depend on what signature scheme your chain uses? When you benchmarked it, did you use only sr25519, or also ed25519 and ecdsa?

Do you expect chains to re-benchmark this themselves?

[shawntabrizi]

@JoshOrndorff yes, we provide the "baseline" implementation, but if you make changes to the assumptions, you will need to redo the benchmarking.

Changing the signature scheme could def cause a change here.

The docs for how we generated that number can be found here: https://www.shawntabrizi.com/substrate-graph-benchmarks/docs/#/extrinsic