[backport] feat: add new cmd fpd commit-pubrand

[bap2pecs]

Summary

backport https://github.com/babylonlabs-io/finality-provider/pull/131/files

Test Plan

$ ./build/fpd unsafe-cpr -h
[UNSAFE] Manually trigger public randomness commitment for a finality provider.
WARNING: this can drain the finality provider's balance if the target height is too high.

Usage:
  fpd unsafe-commit-pubrand [fp-eots-pk-hex] [target-height] [flags]

Aliases:
  unsafe-commit-pubrand, unsafe-cpr

Examples:
fpd unsafe-commit-pubrand --home /home/user/.fpd [fp-eots-pk-hex] [target-height]

Flags:
  -h, --help                help for unsafe-commit-pubrand
      --start-height uint   The block height to start committing pubrand from (optional) (default 18446744073709551615)

Global Flags:
      --home string   The application home directory (default "/Users/<redacted>/Library/Application Support/Fpd")

waiting for CI tests

[bap2pecs]

fixed two lint issues introduced by this PR. but the "rewrite if-else to switch statement" is just refactoring so irrelevant to this PR

[bap2pecs]

rest CI passing

[gitferry]

Could you fix rest of linter errors?

[SebastianElvis]

Btw for backport, we plan to test out this workflow babylonlabs-io/babylon#299. If it works then probably we can port it here

[bap2pecs]

Btw for backport, we plan to test out this workflow babylonlabs-io/babylon#299. If it works then probably we can port it here

How does it work? Will CI auto create a PR?

[SebastianElvis]

Btw for backport, we plan to test out this workflow babylonlabs-io/babylon#299. If it works then probably we can port it here

How does it work? Will CI auto create a PR?

In theory yes, although we haven't seen it working yet

[bap2pecs]

In theory yes, although we haven't seen it working yet

based on my experience backporting PRs, I am not confident it will work. taking this pr as an example,

• TestNewUnregisteredFinalityProviderInstance is only needed in https://github.com/babylonlabs-io/finality-provider/pull/131/files but not this PR. b/c in the base branch, NewFinalityProviderInstance has a check if sfp.Status < proto.FinalityProviderStatus_REGISTERED but main branch doesn't have it
• the API interface in the base branch needs both the client controller and consumer controller as params but the main branch only need client controller due to a very early refactor we did in the base branch

I feel there is no way for the CI to have those knowledge

[SebastianElvis]

For those PRs that do not affect tests or have merge conflicts, this will work. Otherwise, someone needs to modify the PR and get it merged

[gitferry]

@bap2pecs Could you fix the lint error so that we can merge it?

[gitferry]

Thanks for backporting it!