feat(sumeragi): dynamic commit time based on view change index

[Erigara]

Description

• Commit time is now linear function of view change index (capped at Duration::MAX)
• Add more logs to track messages arriving to sumeragi

Note: #4929 would also nice to have because it prevents degradation of view change updates.

Linked issue

Closes #4265

Benefits

This allow to consensus to pass heavy transactions which cause infinite loop previously.

How to test?

Currently it's not possible to modulary test consensus :(

So i've did my tests on bare metal iroha with 4 nodes.

Parameters:

config.toml:

[network]
transaction_gossip_period_ms = 10_000

[transaction]
time_to_live_ms = 3_600_000

genesis.json:

    {
      "Sumeragi": {
        "BlockTimeMs": 100
      }
    },
    {
      "Sumeragi": {
        "CommitTimeMs": 100
      }
    }

Notice that transaction_gossip_period_ms was crucial here, because without it i faced #4952.

Check this comment for the transaction i've submitted to iroha.

[mversic]

this will increase pipeline_time even in the presence of malicious blocks (not just too complex blocks). How about if we add a shift so that first increase in pipeline time is after x first view changes? Thereafter the increase should happen on every view change

[Erigara]

this will increase pipeline_time even in the presence of malicious blocks (not just too complex blocks). How about if we add a shift so that first increase in pipeline time is after x first view changes? Thereafter the increase should happen on every view change

Added shift parameter and made it max_faults + 1 by default, because we can have at most max_faults malicious blocks in a row.

[mversic]

I approve that the growth is linear with view_change_index. We don't want to have exponential growth because malicious peers can have larger impact on the network liveness in that case

[mversic]

let's merge this and split that discussion into a separate ticket