Improve call, and usage in pallet utility

[gui1117]

this decrease the length of call to less than 200 (184 exactly) bytes.
and improve the usage in utility.

companion: paritytech/polkadot#3522

[gui1117]

@jacogr I have 1 question and 1 note:

• Some calls now have a Box<...> for their type instead of just the type directly, the encoding is same as the inner type. Does this needs consideration from UI ?
  (EDIT: in the metadata Box<Foo> will appear instead of Foo)
• batch and batch_all now have a strong limit on the number of batched calls, the limit can be found on metadata, this can also needs consideration from UI.

any remark is welcomed

[jacogr]

Box wrappings are ignored and stripped on the type parsing. (It has no meaning outside the Rust code)

If there is a batch limit on constants, can be read.

[ordian]

have you considered making a static_assertion instead to catch this at compile time instead?
https://docs.rs/static_assertions/1.1.0/static_assertions/macro.const_assert.html

[gui1117]

I gave a try but I think the error message is better with a regular assert.
But all in all this assert is not really important there is no important issue with using a big call enum

error[E0080]: evaluation of constant value failed
    --> bin/node/runtime/src/lib.rs:1632:3
     |
1632 | /         static_assertions::const_assert!(
1633 | |             core::mem::size_of::<Call>() <= 20,
1634 | |         );
     | |__________^ attempt to compute `0_usize - 1_usize`, which would overflow
     |
     = note: this error originates in the macro `static_assertions::const_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

[bkchr]

Until const panics are a thing, static assertions are rather useless.

[shawntabrizi]

200 is an arbitrary number?

[gui1117]

yes IIRC it is the same number as clippy lint

[kianenigma]

what clippy lint?

[gui1117]

this one https://rust-lang.github.io/rust-clippy/master/#large_enum_variant

[shawntabrizi]

looks okay to me, probably need more input from others

[bkchr]

Until const panics are a thing, static assertions are rather useless.

[kianenigma]

LGTM + https://github.com/paritytech/substrate/pull/9418/files#r675454591

[shawntabrizi]

if we want to prevent a large memory allocation before decoding, this pr is not good enough. this would only prevent it after decode

the proposed solution from sr labs is to instead make the signature of batch take vec<box<call>> where now we know each box<call> will be 4 bytes, and then the vec should have no problems w/ size before decode.

However, this is potentially a huge performance decrease, especially as the vec size increases

TODO: Follow up

[gui1117]

the proposed solution from sr labs is to instead make the signature of batch take vec<box<call>> where now we know each box<call> will be 4 bytes, and then the vec should have no problems w/ size before decode.

it is implemented here #9339

[bkchr]

if we want to prevent a large memory allocation before decoding, this pr is not good enough. this would only prevent it after decode

If we can not decode a call, it is invalid anyway. I don't see the reason why we need to work here on better solutions.

[gui1117]

I think this PR improve call by reducing its size, and makes utility batch function limit more explicit for users.

So we can merge it. Otherwise we can close it

[bkchr]

I'm for merging this.

[shawntabrizi]

okay, then lets go ahead and do that :)

I just wanted to post what was said in my last meeting with the auditors.

[gui1117]

bot merge

[ghost]

Waiting for commit status.