fix: enable pagination and introduce new response data in queries

[insumity]

Description

Closes: #2385, #2386

Testing

To verify pagination works as expected for list-consumer-chains, we locally modified contrib/local-testnet.sh so that it starts 150 consumer chains and then we opt in to some of those chains in order to launch them. Specifically, we launch 112 of those chains and then executed commands similar to the ones below to verify everything works as expected:

When counting all the chains:
./build/interchain-security-pd query provider list-consumer-chains --node http://127.0.0.1:29170 --count-total
we get:

...
pagination:
  next_key: AAAAAAAAAAMxMDA=
  total: "150" // total number of consumers chains

When counting all the Launched chains:
./build/interchain-security-pd query provider list-consumer-chains 3 --node http://127.0.0.1:29170 --count-total
we get:

...
pagination:
  next_key: AAAAAAAAAAMxMjY=
  total: "112" // total number of Launched chains

When counting all the Registered chains:
./build/interchain-security-pd query provider list-consumer-chains 1 --node http://127.0.0.1:29170 --count-total
we get:

...
pagination:
  next_key: null
  total: "38" // 150 - 112 = 38 total number of Registered chains (chains that failed to launch).

Additionally, queries like this
./build/interchain-security-pd query provider list-consumer-chains 1 --node http://127.0.0.1:29170 --limit 2 --page-key "AAAAAAAAAAI3OQ==" --reverse
work as expected by returning Registered chains in the reverse order.
Note that when page-key is used the total count is not computed (see FilteredPaginate).

Also the following query works as expected:
./build/interchain-security-pd query provider list-consumer-chains 3 --node http://127.0.0.1:29170 --limit 2 --page 4
by returning the 5th page (0-index on pages) of initialized chains with 2 chains in each page.

---

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 the change is state-machine breaking
• Confirmed this PR does not introduce changes requiring state migrations, OR migration code has been added to consumer and/or provider modules
• Targeted the correct branch (see PR Targeting)
• Provided a link to the relevant issue or specification
• Followed the guidelines for building SDK 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
• If this PR is library API breaking, bump the go.mod version string of the repo, and follow through on a new major release

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 ! the type prefix if the change is state-machine breaking
• confirmed this PR does not introduce changes requiring state migrations, OR confirmed migration code has been added to consumer and/or provider modules
• 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

[MSalopek]

LGTM

[mpoke]

@insumity Please update the docs and add a changelog entry.

[insumity]

@mpoke are we supposed to add .changelog entries for all PRs even so small ones like this one?
Not sure what you mean by updating the docs. I do not think we should add information on how to use pagination on the docs, this should be obvious.

[mpoke]

are we supposed to add .changelog entries for all PRs even so small ones like this one?

Yes if they change something that users might be interested in.

Not sure what you mean by updating the docs. I do not think we should add information on how to use pagination on the docs, this should be obvious.

If the query doesn't change its behavior, then it's fine to not have the docs updated.