…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24

…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24

…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24

…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24

…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24

First step of #24

This PR moves the voting power distribution update algorithm to
`x/finality`. This is a major refactoring that includes

- moving `max_active_finality_providers` parameter to `x/finality`
- moving many functions in `x/btcstaking/power_dist_change.go` and
relevant tests to `x/finality`
- moving test utilities under `x/btcstaking/keeper_test.go` to a new
module `testutil/btcstaking-helper`, and use it for existing tests of
`x/btcstaking` and `x/finality`
- removing the cyclic dependency between `x/btcstaking` and
`x/finality`, as well as their hooks. Now the hooks in these 2 modules
are not necessary, as the only dependency between them is that
`x/finality` will invoke `x/btcstaking`, but not the other way

TODOs in subsequent PRs:

- moving some relevant query APIs to `x/finality`
- moving the voting power dist cache and voting power table KV stores to
`x/finality`

First step of #24

This PR moves the voting power distribution update algorithm to
`x/finality`. This is a major refactoring that includes

- moving `max_active_finality_providers` parameter to `x/finality`
- moving many functions in `x/btcstaking/power_dist_change.go` and
relevant tests to `x/finality`
- moving test utilities under `x/btcstaking/keeper_test.go` to a new
module `testutil/btcstaking-helper`, and use it for existing tests of
`x/btcstaking` and `x/finality`
- removing the cyclic dependency between `x/btcstaking` and
`x/finality`, as well as their hooks. Now the hooks in these 2 modules
are not necessary, as the only dependency between them is that
`x/finality` will invoke `x/btcstaking`, but not the other way

TODOs in subsequent PRs:

- moving some relevant query APIs to `x/finality`
- moving the voting power dist cache and voting power table KV stores to
`x/finality`

First step of #24

This PR moves the voting power distribution update algorithm to
`x/finality`. This is a major refactoring that includes

- moving `max_active_finality_providers` parameter to `x/finality`
- moving many functions in `x/btcstaking/power_dist_change.go` and
relevant tests to `x/finality`
- moving test utilities under `x/btcstaking/keeper_test.go` to a new
module `testutil/btcstaking-helper`, and use it for existing tests of
`x/btcstaking` and `x/finality`
- removing the cyclic dependency between `x/btcstaking` and
`x/finality`, as well as their hooks. Now the hooks in these 2 modules
are not necessary, as the only dependency between them is that
`x/finality` will invoke `x/btcstaking`, but not the other way

TODOs in subsequent PRs:

- moving some relevant query APIs to `x/finality`
- moving the voting power dist cache and voting power table KV stores to
`x/finality`

Second half of #24 

This PR moves the voting power table/cache and relevant APIs to
`x/finality`. This includes the following

- [x] move voting power table KV store to `x/finality`
- [x] move voting power dist cache to `x/finality`
- [x] move 4 APIs `ActiveFinalityProvidersAtHeight`,
`FinalityProviderPowerAtHeight`, `FinalityProviderCurrentPower`,
`ActivatedHeight` to `x/finality`
- [x] fix fuzz tests
- [x] fix e2e tests
- [x] fix doc
- [x] fix changelog

Note that this affects many LoCs since it touches a bunch of proto
files. The actual modification is much smaller than it looks like.

First step of #24

This PR moves the voting power distribution update algorithm to
`x/finality`. This is a major refactoring that includes

- moving `max_active_finality_providers` parameter to `x/finality`
- moving many functions in `x/btcstaking/power_dist_change.go` and
relevant tests to `x/finality`
- moving test utilities under `x/btcstaking/keeper_test.go` to a new
module `testutil/btcstaking-helper`, and use it for existing tests of
`x/btcstaking` and `x/finality`
- removing the cyclic dependency between `x/btcstaking` and
`x/finality`, as well as their hooks. Now the hooks in these 2 modules
are not necessary, as the only dependency between them is that
`x/finality` will invoke `x/btcstaking`, but not the other way

TODOs in subsequent PRs:

- moving some relevant query APIs to `x/finality`
- moving the voting power dist cache and voting power table KV stores to
`x/finality`

Second half of #24 

This PR moves the voting power table/cache and relevant APIs to
`x/finality`. This includes the following

- [x] move voting power table KV store to `x/finality`
- [x] move voting power dist cache to `x/finality`
- [x] move 4 APIs `ActiveFinalityProvidersAtHeight`,
`FinalityProviderPowerAtHeight`, `FinalityProviderCurrentPower`,
`ActivatedHeight` to `x/finality`
- [x] fix fuzz tests
- [x] fix e2e tests
- [x] fix doc
- [x] fix changelog

Note that this affects many LoCs since it touches a bunch of proto
files. The actual modification is much smaller than it looks like.