fix(protocol): re-check operation size before propagation

[damip]

Summary

The operation propagation loop accepted every PropagateOperations(Storage) command and marked all contained operations checked, stored them, and announced them without re-checking the protocol rule serialized_size() <= max_serialized_operations_size_per_block. Locally submitted operations (JSON-RPC / gRPC) are not validated against this limit on submission, so an oversized-but-otherwise-valid operation could be advertised to peers, causing honest peers to ban/disconnect from this node.

Addresses AI-report Finding 125 (severity: medium).

Fix

Filter operations through the new operations_within_size_limit helper before marking them checked / storing for propagation / announcing. This mirrors the size check already enforced on the peer-received (retrieval) path (note_operations_from_peer). Oversized operations are dropped (and logged), not propagated.

Scope / safety

No wire/consensus format change and no JSON-RPC/gRPC interface change — only which locally supplied operations get gossiped. Operations that honest peers would reject as oversized are simply not advertised.

Testing

• oversized_operations_are_filtered_out_of_propagation: with a generous limit an operation is kept; with a limit below its serialized size it is filtered out (so never marked checked/stored/announced).
• cargo test -p massa_protocol_worker --features test-exports: pass. cargo clippy --all-targets: clean. cargo fmt: clean.

Checklist

• document all added functions
• try in sandbox /simulation/labnet
• unit tests on the added/changed features
  • make tests compile
  • make tests pass
• add logs allowing easy debugging
• if the API has changed, update the API specification (n/a)

Made with Cursor

[Leo-Besancon]

Is preventing propagation enough? Would it be possible to directly check this limit against submitted ops (JSON-RPC / gRPC) and return an error there?

Here I think we basically silently drop the operation, no?