refactor: validator's naive N GenServer and Supervisor removal

[rodrigo-o]

Motivation

This is part of the effort for removing all GenServers and redesign the concurrency architecture from scratch

Description
In this PR I'll tackle the most basic way for the GenServer removal, it doesn't deal with some well-needed refactors (like sharing duties and avoid duplicated work), it just starts to manage state at the ValidatorManager level. After going through some issues regarding the attestation and block proposal it wasn't posible to execute the notification for Validators Synchronously inside the Clock as it was done. Temporarily reintroduce one GenServer instead of the previous N, for the ValidatorManager.

Important issues to tackle in future PRs

This is not an exhaustive list but could point int the right direction.

• Right now the get_current_time was a Genserver.call in the Clock. This is generating locks when the validators are executed syncroneously in the tick. The Clock will be removed later but in the meantime getting rid of the get_current_time will free the next issue to be taken
• Remove the GenServer from the ValidatorManager after solving the previous issue
• Do an in-depth refactor of the Validators & ValidatorManager state management. This PR didn't deal with those, it maintained the previous way of managing it and just moved the validators state to the ValidatorManager.
  • slot and root should be shared
  • duties should be shared and calculated once per epoch (updated just when needed)
  • better handle what information we have of each validator at the ValidatorManager level, for example regarding if they are or not setup
• Do an in-depth refactor of the Validator and Validator Manager Logic
  • Check for duplicated block procesing
  • Just execute the ticks for the validators which have duties on those slots

Issues

Solves #1178

[Arkenan]

LGTM! Some comments that may be for next PRs:

• A validator's state has a head_slot and head_root, which are shared by all. We might want to have them in the validator manager instead, and add those to the function calls. Not sure if that simplifies or complicates the code, but it deduplicates the variables.
• Maybe we should have the uninitialized validators in a separate variable instead of having them mixed and notifying them all. This is completely up to discussion and opinionated, but I do find it a bit weird to have a try_setup on every notification instead of trying that in the manager each time there's a change of target state.

[rodrigo-o]

A validator's state has a head_slot and head_root, which are shared by all. We might want to have them in the validator manager instead, and add those to the function calls. Not sure if that simplifies or complicates the code, but it deduplicates the variables.

Yes, totally agree, I'll be more explicit in the PR description about this, I'll gathered it upon the "it doesn't deal with some well-needed refactors", but yes, both head and slot as well as duty management should be shared. I didn't know either if it simplifies things or not but also agreed that's not the place for it. I just tried to touch ligic as fewer as possible in this PR, and add more logging.

Maybe we should have the uninitialized validators in a separate variable instead of having them mixed and notifying them all. This is completely up to discussion and opinionated, but I do find it a bit weird to have a try_setup on every notification instead of trying that in the manager each time there's a change of target state.

Also agree, they are hard to track, up until now it wasn't an issue except for the validators just being there doing nothing, and as far as i could see the condition for them not being able to initialize is the lack of the public key in the validators set. I just ignore the calls in those cases for now instead of retrying the setup which wouldn't work in the new schema, holding all the validators until this ones correctly set up. I also think this is part of the deeper refactor.

[Arkenan]

LGTM!