Implement Validator database functionalities

[GMKrieger]

📚 Context

The base migrations (#347) guarantee only minimal functionality for the database, and tables and functions to support it. It's, as the name implies, the first block from which other blocks can be built upon, and need nothing else to exist.

The validator will need additional support to execute its task, and the repository needs to be updated beforehand to accommodate this. We will need to create additional tables, relations, constraints, as well as implement ways to interact with this information in a safe and atomic way.

It's important to bring attention to how we interact with the data to keep the database consistent, as some transactions are only valid if all the parts move accordingly.

✔️ Solution

The database model will be updated to the following:

Four new tables will be created:

• The node_state table contains only one tuple, doesn't have any way to insert besides an initial setup, and updates with pertinent values that can be accessed by the Node as needed.
• The epochs table contains the start block and end block of each epoch
• The claims table contains the InputRange required to index epoch hashes by the contracts, the epoch hash and the application address
• The proofs table contains the calculated proof, and is connected to the input that generated the output, the output that the proof was calculated and the claim that triggered the process

The validator mock (#369) has an interface on how he expects to interact with the database, and will be implemented as requested.

📈 Subtasks

• Create new migration for the validator
• Implement necessary repository functions
• Create tests for the new functions

[marcelstanley]

Done at #433