GH-686 Don't allow extreme rate packs; reject Gossip about extreme rate packs

[dnwiebe]

Note

Introduces configurable limits for rate packs and upgrades the database schema.

• Add rate_pack_limits (parsed/validated via regex) to persistent config; ensure low<high for all RatePack fields
• New migration 11→12 inserts default rate_pack_limits; bump CURRENT_SCHEMA_VERSION to 12
• Seed defaults in DB initializer and null DAO; expose through PersistentConfiguration; add PersistentConfigurationInvalid and a factory to open DB on demand
• Improve Gossip debugging: AccessibleGossipRecord implements Display and agrs_to_string helper
• Test hardening: adjust timeouts/node counts, add Docker network create retry/removal, update expected rate-pack test values
• Minor: enable time crate local-offset feature; small test refactors/renames; .gitignore tweak

^{Written by Cursor Bugbot for commit c5374e6. This will update automatically on new commits. Configure here.}

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Bug: Slice bounds panic when no space found in string

The Display implementation for AccessibleGossipRecord searches for a space character starting at position 9 in inner_string. If no space is found before the end of the string, the while loop exits with index_of_space_after_pk equal to inner_string.len(). The subsequent slice &inner_string[index_of_space_after_pk + 1..] would then try to create a slice starting at len + 1, causing an index out-of-bounds panic. The code assumes a space always exists but doesn't verify one was actually found before using the index.

 

[cursor]

Bug: Rate pack limits panics instead of returning errors

The rate_pack_limits() function returns Result<RatePackLimits, PersistentConfigError> but panics on syntax errors and invalid limit ordering instead of returning errors. This is inconsistent with similar functions like rate_pack(), payment_thresholds(), and scan_intervals() that use combined_params_get_method and properly return parsing errors via the Result type. The syntax error handling via unwrap_or_else(|| panic!(...)) and the validation in check_rate_pack_limit_order that panics on low >= high both violate the function's contract of returning errors.

Additional Locations (1)

• node/src/db_config/persistent_configuration.rs#L742-L750