staking: 🥞 get_validator_info() uses consensus set

[cratelyn]

see #3846.

🔍 changes

NB: this branch performs a refactor away from validator_definitions() and subsequently moves the definition of that method. this is done in distinct commits, which reviewers are encouraged to examine independently.

staking: 🥞 get_validator_info() uses consensus set

The staking component query service provides a ValidatorInfo RPC that returns
the list of registered validators, optionally filtering Inactive validators.

The way this method is implemented is by using an internal
ValidatorDataRead::validator_definitions methods which returns every single
definition ever submitted to the chain. This is problematic because this list
will inevitably grow quite large, turning usage of a benign-looking method
into an onerous source of I/O and expensive rendering.

this refactors the validator_definitions() method to only return validators
included within the consensus set. this will prevent the list returned from
becoming too large over time.

app: 🧙 ValidatorDataReadExt::validator_definitions()

these methods are tremendously useful for tests, because they save us the
trouble of repeatedly hassling with a Stream. to discourage future use of
them in production code however, we can define these in a test-specific
extension.

this commit introduces ValidatorDataReadExt. validator_identity_keys() is
also moved, as it is subject to the same performance considerations.

checklist before requesting a review

• if this code contains consensus-breaking changes, i have added the "consensus-breaking" label. otherwise, i declare my belief that there are not consensus-breaking changes, for the following reason:

  this only changes the behavior of an RPC endpoint

[cratelyn]

❓ question for reviewers

there is a third to-do item mentioned in #3846, regarding a pcli query validator status command. i'd like to do that in a subsequent PR if possible, to keep this branch focused specifically on the changes to ValidatorDataRead.

is that reasonable, or is the need to inquire about validator state acute enough that i should do that here?

[cratelyn]

❓ question for reviewers

there is a third to-do item mentioned in #3846, regarding a pcli query validator status command. i'd like to do that in a subsequent PR if possible, to keep this branch focused specifically on the changes to ValidatorDataRead.

is that reasonable, or is the need to inquire about validator state acute enough that i should do that here?

i've opened #4263. the changes to pcli ended up being a straightforward change. it is still kept distinct from the core changes here to facilitate review.

[cratelyn]

🥖 breadcrumbs for review.

[erwanor]

Awesome

[cratelyn]

rebased onto main at dc8eff9 ♻️