Use built-in pagination instead of loops.

[jmcarp]

Now that the aws sdk has built-in pagination methods, we don't have to write loops and track pagination tokens by hand.

[jmcarp]

Ping @nickatsegment. This won't change behavior but makes pagination a little simpler to reason about. Plus, we're already using built-in pagination from the sdk elsewhere in the code.

[nickatsegment]

Sounds good to me. I'll give the other core guys a day to comment; I'm not as familiar with the AWS API

[nickatsegment]

I ran the backend benchmarks against master and this PR with

master

$ aws-okta exec dev -- go test -v -run TestSSMConcurrency ./store/... -args -benchmark
=== RUN   TestSSMConcurrency
--- PASS: TestSSMConcurrency (57.53s)
    backendbenchmarks_test.go:55: Concurrently started 1 services in 71.781476ms
    backendbenchmarks_test.go:55: Concurrently started 10 services in 88.639232ms
    backendbenchmarks_test.go:55: Concurrently started 500 services in 25.108277943s
    backendbenchmarks_test.go:55: Concurrently started 1000 services in 29.871719893s
PASS
ok  	github.com/segmentio/chamber/store	57.562s

jmcarp:aws-paginators

go test -v -run TestSSMConcurrency ./store/... -args -benchmark
=== RUN   TestSSMConcurrency
--- PASS: TestSSMConcurrency (47.05s)
    backendbenchmarks_test.go:55: Concurrently started 1 services in 86.868467ms
    backendbenchmarks_test.go:55: Concurrently started 10 services in 89.982798ms
    backendbenchmarks_test.go:55: Concurrently started 500 services in 14.122713244s
    backendbenchmarks_test.go:55: Concurrently started 1000 services in 30.471584343s
PASS
ok  	github.com/segmentio/chamber/store	47.085s

I don't think this test is especially trustworthy (could easily be affected by rate limits from other sources), but it looks roughly the same.

[systemizer]

Didn't know aws had these builtin paginators. Makes sense to me! tested locally and working as intended. thanks again for the contribution @jmcarp !