Send whole transaction pool upon subscription to gossip

[AurelienFT]

Linked Issues/PRs

Part of #1049

Description

This PR introduce a new workflow when we successfully subscribed to the TX topic in gossip we try ask for all the tx_ids in the pool's peer and then ask the full transactions that we don't have.
This PR also build the SharedState of P2PService independently to give more flexibility to the initialisation and avoid cyclic dependencies.

Detailed workflow :

• When a peer has subscribed to our topic send inform the TxPool
• The TxPool asks the tx ids of the peer
• The TxPool filter the one it already knows and ask for the full transactions of the others (a multi message send should be done if the number of txs asked is above the limit (currently 10k chosen randomly)).
• We verify and add them to our txpool

Questions for review

• What's happens if the peer doesn't answer to a request that we await ?
• I placed Option in the request/response because there was in the other messages but why it's needed ?

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests
• The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

[AurelienFT]

@rymnc The PR is still in draft because I still need to make tests but you can start take a look the logic shouldn't change much.

Thankssss <3

[rymnc]

@rymnc The PR is still in draft because I still need to make tests but you can start take a look the logic shouldn't change much.

Thankssss <3

will look at it deeply tomorrow, hope that works!

[rymnc]

looking good, however, I don't think we can call this "gossip" since its a direct p2p request/response protocol given that we make the request to the peer directly (peer_id) as part of the request.

What's happens if the peer doesn't answer to a request that we await ?

we should have a timeout for waiting for the response, and then try another peer (cc: @xgreenx for confirmation)

I placed Option in the request/response because there was in the other messages but why it's needed ?

for the other data we're sending over the req/res protocol (sealed_block_headers and transactions), there is a chance that the range provided is greater than the block height, and to handle that we send None for all blocks we don't have data for. We don't need Option usage for transaction pool transactions :)

[AurelienFT]

@rymnc Thanks for your overview and your comments

About :

I don't think we can call this "gossip" since its a direct p2p request/response protocol

I don't think we ever call the request/response gossip, it's just that it's been trigger on the tx gossip topic being subscribed.

We don't need Option usage for transaction pool transactions :)

Will remove that

[rymnc]

In general LGTM, added some comments/questions :)

[Voxelot]

Do we reconcile the txs before or after subscribing? If we start processing gossipped txs while we are still syncing the txpool, we may end up dropping them if they depend on earlier txs that havent been synced yet.

[AurelienFT]

Do we reconcile the txs before or after subscribing? If we start processing gossipped txs while we are still syncing the txpool, we may end up dropping them if they depend on earlier txs that havent been synced yet.

The trigger to make this reconciliation is the subscription so yes it happens just after suscribing. You are right it could lead to invalid gossiped transactions from the point of view of the receiver.
Do you have an idea of when we should make the trigger ?
Because if we activate the gossip after the reconciliation there the possibility that we have miss a child during a period where the gossip wasn't activate too.

Possible solution that I see is, given the tx pool v2 is that all gossiped transactions are queued until we finished at least one peer reconcialition and then we start to process them.
It's pretty easy to do given the fact that in TxPool v2 the verif and insert is done in parrallel manged by a threadpool and a queue