Incorporate Avalanchego signature aggregation

[cam-schultz]

Context and scope
ava-labs/avalanchego#3394 adds a signature aggregation utility to Avalanchego that, when integrated, would allow us to remove a significant amount of duplicate functionality. The new utility uses p2p.Client, which encapsulated much of the p2p request handling that we currently implement ourselves.

Discussion and alternatives
We can replace much of the logic in SignatureAggregator.CreateSignedMessage with a call to this utility. We'll have to refactor the retry logic somewhat, but the utility does support this by accepting a partial aggregate signature as an argument.

We should also be able to replace much of the external handler logic (or remove it altogether), since the utility manages response handling.

Open questions
The Avalanchego aggregator does not support our use case of reconstructing an aggregate signature from cached individual signatures in the event of a validator set change. To do so, we would need a mapping of BLS public key to signature for a particular Warp message ID.

[iansuvak]

The POC implementation of incorporated acp118 aggregator from avalanchego is at #645 . The POC implementation doesn't include caching individual signatures.

It shouldn't be merged because:

• One of the core motivations was removing the amount of network request handling that is being done custom in this repo's peer.Package. This doesn't decrease it at all but increases it since the acp118.aggregator expects a p2p.Client which is created from a p2p.Network which still requires our peers.AppRequestNetwork for things like actual sending of the outbound request as well as handling timeouts and forwarding the requests back to the p2pclient for handling.
• p2p.Client changes the semantics of our outbound sending. Current implementation on the main branch registers a single requestID and calls a single Network.Send() per message being signed. p2p.Client issues separate Send calls for each validator a signature is being requested from. This makes troubleshooting and gathering metrics on signature request level more difficult
• Network.Send requires the knowledge of the subnet-id the request is being sent-to at the time. In order to enable this with the POC implementation, it creates a separate client for each subnetID that is tracked but using the same underlying network. Although tests are mostly passing I imagine this might have potential for requestID collisions? It could potentially be worked around via tracking which nodeIDs are associated with which subnet