Update weight for im-online

[gui1117]

The weight must consider all the cost of executing the extrinsic, validate_unsigned included.
To confirm formula a benchmark has been added.

In order to have the length of Keys it is added as argument of the dispatchable.

Thus the offchain worker is also changed. AFAIK changing the offchain worker doesn't require validators to update their nodes.
But old unsigned transaction submitted will fail, but if I understand the code correctly the offchain worker will try at every block if it is not online yet. @tomusdrw

[gui1117]

Here keys_len isn't part of the signed heartbeat but I think its fine, though one can double-check.

[tomusdrw]

Since imonline transactions have to be propagated to other authorities (since the ones that send it didn't have a chance to produce a block), there is a potential attack, where other authorities change the key_len inside the payload making the transaction invalid.
This is not super bad, since they can also change say session_index or simply censor the transactions, but with key_len we can't be sure what happened - we don't know if the authority is misbehaving or it was maliciously modified. The possible cases are:

1. The hearbeat is incorrect, but has correct signature (i.e. the authority is misbehaving).
2. The heartbeat is incorrect and has incorrect signature (i.e. was modified).
3. The heartbeat was not seen (i.e. either not sent or censored).
4. Key_len invalid (i.e. either modified or authority misbehaving).

I'd be for putting that into Heartbeat payload for simplicity, unless there are any reasons why we should not do that.

[tomusdrw]

Re discussions in benchmarking channel, we should probably use saturating ops here, since key_len is coming from the user.

Even though the transaction should be rejected, I think the overflow may have some unforseen consequences (for instance it will panic in debug mode), so better have saturating ops for everything here.

[gui1117]

ok for the saturation, params should have been checked in validate_unsigned but better be safe anyway.

I updated to put key_len part of heartbeat. 👍

[tomusdrw]

Looks good besides the possible improvement with key_len being signed as well.

Changing offchain workers does not require updating the nodes. Indeed old transactions will fail in case runtime update is performed in unlucky moment, but also as Gui mentioned, the OCW code will attempt to send another one after the grace period is over and the previous transaction was not included.

[tomusdrw]

Since imonline transactions have to be propagated to other authorities (since the ones that send it didn't have a chance to produce a block), there is a potential attack, where other authorities change the key_len inside the payload making the transaction invalid.
This is not super bad, since they can also change say session_index or simply censor the transactions, but with key_len we can't be sure what happened - we don't know if the authority is misbehaving or it was maliciously modified. The possible cases are:

1. The hearbeat is incorrect, but has correct signature (i.e. the authority is misbehaving).
2. The heartbeat is incorrect and has incorrect signature (i.e. was modified).
3. The heartbeat was not seen (i.e. either not sent or censored).
4. Key_len invalid (i.e. either modified or authority misbehaving).

I'd be for putting that into Heartbeat payload for simplicity, unless there are any reasons why we should not do that.