[payment] prune reservation periods and ondemand payments

[hopeyen]

Why are these changes needed?

To avoid db from infinitely growing, we prune reservations and ondemand records

reservations are pruned periodically with a goroutine similar to refreshing onchain state, as it operates based on time. The frequency is set as a configuration to the offchain store
ondemands are pruned every time a ondemand request is served, with a hardcoded constant which is 100 for each account, this can also be a configuration

also contains some renaming of binRecord to reservationPeriodRecord, and refactoring refreshOnchainState function

Checks

• I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
• I've checked the new test coverage and the coverage percentage didn't drop.
• Testing Strategy
  • Unit tests
  • Integration tests
  • This PR is not tested :(

[ian-shim]

Instead of actively kicking off pruning logic, can we set a TTL for these records and enforce pruning from dynamodb directly?

[hopeyen]

Instead of actively kicking off pruning logic, can we set a TTL for these records and enforce pruning from dynamodb directly?

Yes that makes sense, I will try!