OP: QueryActivatedHeight redesign

[bap2pecs]

currently we manually set the height in the CW contract and query it from there. but per definition at https://github.com/babylonchain/babylon/blob/dev/x/btcstaking/types/query.pb.go#L1774-L1775:

ActivatedHeight queries the height when BTC staking protocol is activated, i.e., the first height when there exists 1 finality provider with voting power

so the way right is to

1. Get all fp list via consumer_id:

   /babylon/btcstkconsumer/v1/finality_providers/{consumer_id}

2. Iterate each fp and get its delegations:

   /babylon/btcstaking/v1/finality_providers/{fp_btc_pk_hex}/delegations

3. For each active delegations, get the start_height(it is the btc height), find the earliest start_height

4. Get the last L2 block number(in 10mins) for the btc height at which the earliest active BTC delegation

but per my discussion w @SebastianElvis, this API is only used in poller — poller waits until the BTC staking is activated, mostly as an optimisation.

so a better mechanism is to let the poller waits until its own FP receives 1 BTC delegation. If the FP does not receive any delegation, it does not make sense to poll, even though BTC staking is activated

this task has low priority as the only downside of current impl is to waste the FP some gas. but in MVP, we only have a handful of FPs so should be fine.

TODOs

• [ ] remove activated height related code in the CW contract

[gitferry]

Some notes from offline discussions:

• waitForActivation is legacy as the protocol is always activated from height 1
• The poller should remain dumb. It should be the finality service to decide which height the poller should start polling
• Ideally, the poller should start from the first height which the FP has voting power for but has not voted

[bap2pecs]

https://github.com/babylonchain/pm-integration/issues/3

The proposed QueryActivatedHeight might not work as the start_height is not necessarily the height that BTC delegation becomes active. To become active, it needs to satisfy 1) the staking tx is k-deep in Bitcoin, i.e., start_height + k and 2) it receives a quorum number of covenant committee signatures