Token claims and vesting runtime tests

[dmitrylavrenov]

Runtime tests for token claims and vesting integration paritytech/substrate#441 .

To do

• test claim call: claiming without vesting works:
  • ensure the claim is gone from the state after the extrinsic is processed
  • ensure the balance of the target account is properly adjusted
  • ensure that the balance is not locked
  • ensure total issuance did not change
• test claim call: claiming with vesting works
  • ensure the claim is gone from the state after the extrinsic is processed
  • ensure the balance of the target account is properly adjusted
  • ensure that the balance is locked
  • ensure that the vesting is armed for the given account and matches the parameters (balance amount, schedule, etc)
  • ensure total issuance did not change
• test unlock call: unlocking partial balance works
  • ensure funds are unlocked
  • ensure rounding works as expected
• test unlock call: unlocking full balance works
  • ensure funds are unlocked
  • ensure rounding works as expected
• genesis tests
  • ensure the genesis initialization does not crash at any of the built-in chainspecs
  • ensure the genesis config is properly parsed with the combination of types we have configured in our runtime
• signed ext tests
  • ensure we don't allow dispatching invalid claim transaction
  • ensure the token claim check signed extension does its job of filtering the the invalid claim transactions, preventing them getting into the transaction pool

[MOZGIII]

Looks good so far, but a couple of changes are required.

• the switch_block helper doesn't look right, we should probably invoke a more realistic block switching or none at all
• the calls are tests via direct invocation, which doesn't test the signed ext, which we should do; I'll add the corresponding entries to the todo list

[MOZGIII]

Great! Now I'll do a more thorough review on this code once again, and either request more changes or we'll be good to merge.

[MOZGIII]

Tests for direct calls need to test for the errors too. Errors have to be tested for:

• direct calls
• dispatch validate
• dispatch pre/post

These three implementations are potentially different, so we need to ensure each of them handles errors (in their own way) correctly.
But still, to clarify, no tests for individual SignedExtensions are needed, only for the combined SignedExtra.