Add timestamp in node validation election

[wassimans]

Description

This pull request addresses an issue with the validation node election process. Currently, the election is based on transaction data and a daily nonce seed, which causes repeated selection of the same validation nodes for identical transactions throughout the day. If one of the validation nodes, especially the coordinator, has an incorrect state or is unable to retrieve required data, the transaction will fail validation for the entire day.

The solution implemented here introduces a timestamp into the election process to ensure that the elected nodes vary with each transaction attempt. The timestamp used is from the StartMining message, sent by the welcome node, which serves as a reference timestamp to diversify node election.

Fixes #1564

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

The following tests were conducted to validate this change:

• Ensuring the seed sorting value changes with changing transactions, and/or ref_timestamp
• Ensuring the seed sorting value doesn't change for identical parameters (transaction, ref_timestamp)
• Ensuring that validation nodes election changes with changing transactions and/or ref_timestamp
• Ensuring that validation nodes election doesn't change for identical transactions and ref_timestamp

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

[bchamagne]

LGTM

[Neylix]

I'm also wondering, in the ValidationContext, when a node cross validate the stamp, it ensure the timestamp is valid. This function could evolve since the timestamp should be the ref_timestamp shared by all validations node

[wassimans]

I'm also wondering, in the ValidationContext, when a node cross validate the stamp, it ensure the timestamp is valid. This function could evolve since the timestamp should be the ref_timestamp shared by all validations node

I now check for equality between the node's validation time and the corss validation time.

For consistency, I also modified the following test/archethic/mining/validation_context_test.exs:252, from "should validate even if validation_time and cross_validation_time are in different oracle bucket" to "should not validate if validation_time and cross_validation_time are in different oracle bucket" and made sure ":timestamp" is present in the inconsistencies table.

The test in test/archethic/mining/validation_context_test.exs:252 ("should validate with a valid validation stamp"), should handle the happy path for us without change.