Add tmp trie store implementation in snapshot processor

[rmoreliovlabs]

Description

Add tmp trie store implementation in snapshot processor

For validating if the trie structure is correct within the Temporary Datasource:

1. We need to confirm every node exists in the trie.
2. We need to make sure every children referenced from the parent node exists in the DB.
3. Sinc all messages are coming in chunks, we should consider that not all children might be in the same chunk. So if you don’t find a child in a chunk, we should check if we can find it in the DB.
4. If we don’t find a hash in the trie or the DB, then we can say the trie is invalid.
5. If all the checks are fine, then we move the node to the Actual Trie and delete it from the Temporary Datasource

When the validation is successful, we can move the content from the Temporary Datasource to the actual Trie Store. We need to make sure the temporary entries are deleted after data is moved.

Motivation and Context

Considering the snap sync protocol working theory, we will use a Temporary Trie Store to save the snap sync chunk messages and validate it. One we the validation succeeds , we can move all the data from the Temporary Datasource to the Actual Trie Store

In this PR we are adding the changes to store snap chunks in temporarydatasource and when the snap sync finishes we move it to the Actual Trie Store and clean the Temporary Datasource.

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• Tests for the changes have been added (for bug fixes / features)
• Requires Activation Code (Hard Fork)

• Other information:

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 55%)

See analysis details on SonarQube Cloud

[fmacleal]

Good job!

I just have a few comments and questions.

[fmacleal]

question:

why this value is -1? What is this value used for? Is it a seed? If it's a seed, wouldn't be better to be a random value?

[rmoreliovlabs]

this is where the size of the nodes are stored, since we are storing things in a key / value map, we don't have the size of the nodes and RocksDB might create other keys in it's inner workings. We want that size to iterate all the nodes in the map because the key is the index of the node as the nodes were in a list

[fmacleal]

But if it's a key value map, why not have it set as a random final value instead of a fix -1? The key is fixed, if a new key clashes with this one, it would fail in RocksDB instead of overwrite no?

The -1 it's predictable, maybe it can easily be changed by someone trying to exploit this no?
If I understood, this is the key where you will store the size of all nodes saved, is it?

[fmacleal]

question:

What are you saving at this part? After you save all the tries you save the size of the nodes you have in the for plus the size of nodes you have saved?

[rmoreliovlabs]

I am storing the size of the nodes when every chunk arrives. Each chunk comes with a new list of nodes to be added, so we need to keep the size of the nodes up to date

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
85.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud