chore: QueryFinalityProviderHasPower returns false if there is no public randomness

[lesterli]

Summary

This PR updates the function QueryFinalityProviderHasPower, it will return false if there is no public randomness at the queried height.

More content: #115 (comment)

Test Plan

open the debug log in op_test_manager.go, line 74: zapcore.InfoLevel -> zapcore.DebugLevel, and then run e2e test:

make test-e2e-op-filter FILTER=TestOpFpNoVotingPower

once it is done, it should have some debug logs, like this but the value of fp pk is different:

    utils.go:100: Public randomness for fp 9ff0d9db0a73b7d4b3aa19b0b6c7f56ec4089ea22194a6b5019f021b8d342487 is successfully committed at height 64
2024-11-22T11:08:30.761+0800    DEBUG   opstackl2/consumer.go:285       FP last committed public randomness     {"height": 64}
2024-11-22T11:08:30.761+0800    DEBUG   opstackl2/consumer.go:290       FP has 0 voting power because there is no public randomness at this height      {"height": 65}

2024-11-22T11:08:31.772+0800    DEBUG   opstackl2/consumer.go:285       FP last committed public randomness     {"height": 64}
2024-11-22T11:08:31.774+0800    DEBUG   opstackl2/consumer.go:326       FP has 0 voting power because there is no BTC delegation        {"fp_btc_pk": "9ff0d9db0a73b7d4b3aa19b0b6c7f56ec4089ea22194a6b5019f021b8d342487", "height": 1}
2024-11-22T11:08:31.774+0800    DEBUG   service/fp_instance.go:474      the finality-provider does not have voting power        {"pk": "9ff0d9db0a73b7d4b3aa19b0b6c7f56ec4089ea22194a6b5019f021b8d342487", "block_height": 1}

Note: For the op e2e test, there is a working branch test/fix-fg-circular-dependency-e2e-tests

[SebastianElvis]

Nit: pubRand.StartHeight + pubRand.NumPubRand - 1 can be a function EndHeight() under pubRand

[bap2pecs]

this is good but there is another case that this check won't cover

what if pubrand is not consecutive? so block 1-100 and 300-400 has PRs. if blockHeight is 200, lastCommittedPubRandHeight will be 400 and it should be considered not having VP

but this check doesn't cover it

[gitferry]

Good point as Babylon allows gaps. Better to add a TODO here.

Also, currently BTC-timestamping is not involved, right?

[bap2pecs]

yes it doesn't need to be in this PR. we can add a TODO

no currently BTC ts is not involved

[bap2pecs]

just curious, why previous CI run never detect these?

[lesterli]

yes, i tested on a new server with ubuntu 22.04, and it works fine.

for go mod tidy, i saw it automatically selects the appropriate version on this new server

go: downloading nhooyr.io/websocket v1.8.17

for make build, the error "invalid CFI advance_loc expression" only occurs on x86 macOS using LLVM 17

so i will revert these changes.