Construct signatures for a specific p-chain height

[iansuvak]

Context and scope
CreateSignedMessage right now assumes that the ProposerVM P-Chain height for the destination chain is the latest height. This is not a valid assumption at all times and it should optionally accept a specific height for which to create a signature since any changes in the signing subnets validator set as viewed by the destination chain (via p-chain) can make the aggregated signature invalid as the validator bit set would change in those cases.

Discussion and alternatives

• Should we expose this in the Signature aggregator interface?
• Ideally we should be able to accept a destination chain id on the api side and translate that to a likely valid p-chain height.

Open questions

[cam-schultz]

As an alternative to #506 , we may want to instead integrate the following Avalanchego changes once they are merged:

• Add GetProposedValidators RPC. Add getProposedValidators RPC method avalanchego#3497
• Allow non-primary network validators to fetch all peers Allow non primary network validators to request all peers avalanchego#3491

This will allow us to fetch the valdiator set that will be used to verify signatures on the L1 side directly from the P-Chain. We will also be able to connect to validators of any L1 without requiring manual tracking or L1-specific API nodes.