Fix slot missing transaction

[Neylix]

Description

Actually, when it's the time for a new slot, the slot timer send a event to all the subset to process the slot creation.
But due to some latency for a slot node to receive the ReplicationAttestation message or simply the latency for a transaction to be replicated, the slot node may have build and sent the slot before receiving all the slot transaction.

For example:

To solve this problem, here is the new workflow:

• We don't verify that a replication attestation is in the right slot time. Any attestation can be in any slot.
• When building the summary, we control that the number of confirmations of an attestation reach a certain threshold (35%) of the expected confirmations number. If it not reaches the threshold, the attestation is postponed to the next summary.
• As we can have postponed attestation in a next summary, we ensure the attestation is between 2 previous summary and current summary.

Here is an example:

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Neylix]

After some discussion, a better way to handle this problem has been found:
When a node receive a replication attestation it will add it to the current slot if the tx timestamp is over than 2 previous summary time even if the slot time is not the right one.
When it is slot time, every node will send the slot if it is not empty even if the node is not an elected one for the current slot.
On summary time, before adding a replication attestation, the node ensure that there is enough confirmations with a threshold of 35% minimum (threshold if there is at least 10 expected replication nodes) If the threshold is not reached, the attestation is postponed to the next summary by just adding the attestation in the current slot.
During self repair, the same threshold control is performed

[bchamagne]

As discussed, there is an issue with the transactions from last slot being duplicated in 2 summaries (S and S+1).

[Neylix]

As discussed, there is an issue with the transaction from last slot being duplicated in 2 summaries (S and S+1).

I found a way to fix it in this PR, I'll move the threashold verification when creating the aggregate

[bchamagne]

Tested with 3 nodes (minimum_nodes_for_threshold = 2)
I added a 10s sleep to 2/3 nodes.
I created a transfer few second before summary
Transfer postponed as expected. ✔️

(we see the transfer at 40:54 present in the 41->42 summary as expected)