add cost tracking for each bank during replay

[tao-stones]

Problem

Leaders use cost_tracker to ensure each block produced are with block limits. Same cost tracking and checking against limits should be symmetrically performed during replay, blocks exceed limits should fail replay.

Summary of Changes

• calling bank.cost_tracker.try_add(tx) during replaying, return error if block exceeds limits
• add feature gate since this change breaks consensus

Feature Gate Issue: #29595

NOTE: Until this point, cost_model and cost_tracker are exclusively used by leaders during block packing, so we enjoyed the freedom to change how it works without worrying much about breaking consensus. With this PR, future changes to cost_model.rs, cost_tracker.rs, block_cost_limits.rs and maybe other models that would change how transaction cost measures against block limits could break consensus, therefore need to be feature gated.

[steviez]

NOTE: Until this point, cost_model and cost_tracker are exclusively used by leaders during block packing, so we enjoyed the freedom to change how it works without worrying much about breaking consensus. With this PR, future changes to cost_model.rs, cost_tracker.rs, block_cost_limits.rs and maybe other models that would change how transaction cost measures against block limits could break consensus, therefore need to be feature gated.

To confirm,

• Prior to this change, the limits imposed by this files were only checked by leaders
• But, the above wouldn't hypothetically prevent someone with mods from creating blocks that broke some rules
• After this change, non-leaders will begin checking these rules in replay
• Checking of these rules in replay could result in rejecting a block that previously would have been allowed through

And the last bullet is why this could affect consensus, and why we need a feature gate for this change and any subsequent modifications to these file. Is that all correct?

[tao-stones]

NOTE: Until this point, cost_model and cost_tracker are exclusively used by leaders during block packing, so we enjoyed the freedom to change how it works without worrying much about breaking consensus. With this PR, future changes to cost_model.rs, cost_tracker.rs, block_cost_limits.rs and maybe other models that would change how transaction cost measures against block limits could break consensus, therefore need to be feature gated.

To confirm,

• Prior to this change, the limits imposed by this files were only checked by leaders
• But, the above wouldn't hypothetically prevent someone with mods from creating blocks that broke some rules
• After this change, non-leaders will begin checking these rules in replay
• Checking of these rules in replay could result in rejecting a block that previously would have been allowed through

And the last bullet is why this could affect consensus, and why we need a feature gate for this change and any subsequent modifications to these file. Is that all correct?

Exactly, all points correct. Checking during replay prevents large-than-limits blocks from being replayed, potentially causing validators skipping slots.

[steviez]

Things look good to me, but looks like there is a merge issue that will require resolution and thus me looking again since a ship it would get dismissed.

[steviez]

Nice, got the PR down to the bare minimum to introduce the feature gate!

[tao-stones]

Nice, got the PR down to the bare minimum to introduce the feature gate!

Thank you ❤️