feat: add new amounts to a periodic vesting account

[JimLarson]

Description

Refs: Agoric/agoric-sdk#3956

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[michaelfig]

Looking really good! I'm convinced that this is close to the minimal (tested) change needed for this feature.

I would like to see a separate consume(...) helper. Ping me again when you want another review.

[michaelfig]

Could you please factor this logic out into a consume function? It could be either a local-to-mergePeriods closure to avoid passing common arguments, or a file-level helper function.

That would help keep things DRY, make it easier for me to review, and avoid copy-pasta errors.

[JimLarson]

I've refactored along the lines you suggested and I think it's a net improvement. It still uses a grab-bag of function-local variables to hold the iteration state, but I think data abstraction would be more trouble than it's worth.

Another approach I considered was to convert the vesting schedules to use absolute time, merge the schedules more simply, then convert back to relative times. Again, I don't think it's worth the effort.

[JimLarson]

PTAL. Look especially at msg_server.go:220-225 to ensure that I'm updating the vesting account data correctly, and that the test coverage in handler_test.go looks sufficient.

[michaelfig]

Looks great!