CLPR-2.6: Lazy configuration propagation

Story CLPR-2.6: Lazy Configuration Propagation

Parent Epic: CLPR-2: Messaging Layer
Repo: hiero-ledger/hiero-consensus-node

Objective

Implement and verify the lazy config propagation mechanism (cross-platform spec §1.3, Hiero impl spec §3.2.1 step 7, §3.2.2 step 2).

Acceptance Criteria

• AC-1: Each Connection's last_config_timestamp tracks when config was last propagated.
• AC-2: On sendMessage: if last_config_timestamp < current_config.consensus_timestamp, enqueue ConfigUpdate BEFORE the data message.
• AC-3: On submitBundle: same check, enqueue ConfigUpdate during processing.
• AC-4: After enqueue, last_config_timestamp updated to current_config.consensus_timestamp.
• AC-5: ConfigUpdate contains the full current ClprLedgerConfiguration.
• AC-6: ConfigUpdate consumes a message_id slot and extends the running hash like any other message.
• AC-7: Two rapid config changes before traffic produce only one ConfigUpdate (the latest).
• AC-8: Connections with no traffic never incur propagation cost (O(1) admin cost).
• AC-9: Black-box tests: propagation on send, propagation on bundle, multiple config changes coalesce, no propagation when config unchanged, ConfigUpdate correctly serialized and hashed

Notes

This is a cross-cutting concern within ClprSendMessageHandler and ClprSubmitBundleHandler. This story tracks testing and verification of the behavior.

Dependencies

• CLPR-1.2 (configuration must exist)
• CLPR-2.2 and CLPR-2.3 (handlers that implement it)

Risk

Low — Timestamp comparison and conditional enqueue.

Start by reading ClprSendMessageHandler and ClprSubmitBundleHandler, then trace Connection state, configuration timestamps, message IDs, and running-hash updates. Verify propagation on send and bundle submission, coalescing of rapid changes, unchanged configurations, serialization, hashing, and the no-traffic case with black-box tests.