Limit generation/windowed-nonce growth

[theodorebugnet]

Description

Add a sane limit to how much a generation or windowed nonce can grow in a single transaction, to prevent accidental major changes to account state.

The limit is 2x the current value, with exceptions for low values (at least the minimum required for pruning in generations, and at least PAST_WINDOWS for windowed nonces) to avoid excessive friction when the current value is small.

Also updates the module README which was out of date.

• I have updated CHANGELOG.md with a new entry if my PR makes any breaking changes or fixes a bug. If my PR removes a feature or changes its behavior, I provide help for users on how to migrate to the new behavior.
• I have carefully reviewed all my Cargo.toml changes before opening the PRs. (Are all new dependencies necessary? Is any module dependency leaked into the full-node (hint: it shouldn't)?)

Linked Issues

• Fixes # (issue, if applicable)
• Related to # (issue)

Testing

Describe how these changes were tested. If you've added new features, have you added unit tests?

Docs

Describe where this code is documented. If it changes a documented interface, have the docs been updated?

Rendered docs are available at https://sovlabs-ci-rustdoc-artifacts.us-east-1.amazonaws.com/<BRANCH_NAME>/index.html

[bkolad]

The PR LGTM. One question, generation uniqueness now rejects jumps above max(latest * 2, latest + PAST_TRANSACTION_GENERATIONS + 1) but if last is let's say 1000_0000 so the gap can be 1000_0000 and it grows as latest grows is that ok?

[theodorebugnet]

Yep, the main idea is that you can't do 1000x e.g. when accidentally submitting ms time instead of s time. That's been Zeta's main issue