🧩 566 & 645, Aggregate Fix & Fix self repair notifier #645

[apoorv-2204]

Description

Self-Repair:

-Determine which shards plummeted.
-Determine which transactions those shards were in charge of.
-Expand new shards for those transactions.

Proposed Solution :

• Use minimal information to inform the new shard.
  • %ShardRepair{} message with  two fields, the genesis address and the last address.
• The New Shard collects data on its own.
  • Via fetch Transaction and Replicate validate transaction chain
• Handle concurrent task requests using an FSM for each genesis address,to have bottleneck .
  • As a result multiple same job are not deployed concurrently.
• Fix self-repair notifier #645
• Notify beacon summary in case of network topology change #566

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Testing

• Unit tests

To test in real condition we need to update some conditions to limit the number of nodes we need to run.
Here is the patch to apply which change

• number of storage node always return 3
• minimum geo patch to 1 and minimum avg_availability to 0.0
• remove burning fee address from IO storage node
• return static value for coingecko api (just to avoid spamming the API and having error)
• use a static geopatch when the node is a local one
  patch.txt

Then you can run 5 nodes

• wait them to be authorized
• send a transaction
• look for which node stored it (normally 3 nodes)
• stop 1 or 2 of these nodes
  After the next self repair when they goes unavailable, the notifier of each node should be triggered. The last storage node of the transaction should send to 1 or 2 new node the ShardRepair message, and these nodes should replicate it.
  Other node should also replicate a SummaryAggregate if the disconnected node was a storage node for it

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