Rely on docker aliases instead of global envs for clients selection in stakers

[pablomendezroyo]

The current approach for handling the clients selection in the stakers UI is a monolithic solution that makes it hard to add new clients to any network, adds a lot logic to the entrypoints of the client and forces packages to be restarted to realize about the new client selected among other disadvantages.

A cleaner and more simple solution would be to create a new docker network staker_network and use unique docker aliases per network and docker host and hardcode these aliases in the entrypoints of each client, trusting that the dappmanager will take care on setting the correct alias whenever the user selects a client.

There will be a pair of docker aliases per network and they will look something like:

• execution.network.dappnode
• consensus.network.dappnode
• signer.network.dappnode
• mev-boost.network.dappnode

The implementation in the dappmanager will be:

• [ ] Ensure aliases' uniqueness.
  • docker does not ensure aliases uniqueness which might result in DNS conflict resolution. Currently, the docker aliases are:
    • container ID
    • container name DAppNodePackage-api-ui.ethical-metrics.dnp.dappnode.eth
    • service name (custom): api-ui
    • serviceName.dnpName.dappnode (custom): api-ui.ethical-metrics.dappnode
  • [ ] Do not allow setting of custom aliases in compose files in the dappnode installer and SDK
  • [ ] ENS ensures already uniqueness so dappmanager installer just need to ensure none packages have other ens as aliases or part of its aliases.
• [ ] docker network staker_network settings must be persisted in docker compose files for resilience
• [ ] The staker UI selection will consist of:
  1. Disconnect prev client, stop it and remove settings from compose
  2. Add docker network settings to compose and startup
• [ ] Test if containers need or does not need to be restarted to avoid cache issues whenever the container behind the unique alias changes
• [ ] Keep setting global envs for backwards compatibility
• [ ] Keep the existing dncore_network configuration
• [ ] Initial migration for setting the aliases of the clients selected for the first time

The work in the packages will be:

• [ ] Use of fullnode execution in consensus clients, removal of unused global envs and clean entrypoints
• [ ] Use of fullnode consensus in execution clients, removal of unused glglobalonbal envs and clean entrypoints
• [ ] Set minimumDappnodeVersion that supports the fullnode aliases implementation
• [ ] Use 1 jwt per network, this will be a breaking change and in orther to make these packages updated at the same time the usage of optionalDependencies might be required