fix: ValidatorStore interface doesn't match StakingKeeper

[facundomedica]

Description

Closes: #17163

We had to add the necessary functions directly to the Staking Keeper given that when you have an interface with a function that returns another interface, you can't make another interface comply because the returning interface won't be accepted (example: https://go.dev/play/p/tz50jVl0NBw).

---

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
• run make lint and make test
• 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)

[julienrbrt]

I don't know how we can make sure these interfaces match without creating new dependency, but it would be good to do it somehow (maybe implementing it on Simapp).

We could just have a function call in /integration/ to, it does not pollute simapp.

[julienrbrt]

We should update the ADR as well

cosmos-sdk/docs/architecture/adr-064-abci-2.0.md

Line 220 in bd61e84

GetValidatorByConsAddr(sdk.Context, cryptotypes.Address) (cryptotypes.PubKey, error)

[facundomedica]

Moving this to draft as I'm writing an integration test

[tac0turtle]

I don't know how we can make sure these interfaces match without creating new dependency, but it would be good to do it somehow (maybe implementing it on Simapp).

can we import baseapp for now into staking to make sure it matches, later on we can fix the dependency but for now i think its fine

[alexanderbez]

I don't know how we can make sure these interfaces match without creating new dependency, but it would be good to do it somehow (maybe implementing it on Simapp).

can we import baseapp for now into staking to make sure it matches, later on we can fix the dependency but for now i think its fine

I wanted to avoid this if possible honestly. I think we tweak the API(s) to avoid this but if we cannot, then yes, this is a fallback

[facundomedica]

@tac0turtle @alexanderbez I just saw your comments, in my last commit I've added the necessary APIs to the staking keeper + an integration test. lmk what you think

[julienrbrt]

lgtm!

[julienrbrt]

Curious, isn't it slower now because we get the validator twice? While before only once.
It is probably negligible but just curious. :D

[facundomedica]

Yes, it will be slower sadly. We could have a specific API that returns both bonded tokens and public key, wdyt?

[julienrbrt]

No objection to that personally.

[alexanderbez]

@facundomedica yes let's do that. This will be used in the VE hotpath so we don't want obvious performance slowdowns

[facundomedica]

Added BondedTokensAndPubKeyByConsAddr