Move defaultDataDir procedure to nimbus_binary_common.

[pedromiguelmiranda]

This intends to fix all Nimbus clients declaring the same function, and once its merged, unify this use on all of them.

[github-actions]

Unit Test Results

       15 files  ±  0    2 619 suites  +5   1h 13m 17s ⏱️ - 7m 53s
  6 414 tests +  2    5 893 ✔️ +  2  521 💤 ±0  0 ❌ ±0 
44 626 runs  +10  43 908 ✔️ +10  718 💤 ±0  0 ❌ ±0 

Results for commit 23fa283. ± Comparison against base commit 7b2a674.

♻️ This comment has been updated with latest results.

[cheatfate]

This is definitely should not be string literal, because its easy to make mistake which you have made.

[pedromiguelmiranda]

thanks. Which mistake was made?
Ok, I see your point, force type checking with an enum or a table. That would be interesting, however check the comments below.
Deserves a const though

[cheatfate]

This is not BeaconNode configuration it is Validator Client configuration.

[pedromiguelmiranda]

thanks.
all of these declarations were using the same defaultDataDir procedure with "BeaconNode" hardcoded on the procedure it self.
I just made it generic, and move it from beacon_chain/conf to nimbus_binary_common module.

Is it safe to start using a diferent data dir for each client and/or component?

[cheatfate]

This is not BeaconNode configuration it is Signing Node configuration

[pedromiguelmiranda]

same comment as before.

[arnetheduck]

The general direction we want to be going in is that we have a directory structure that allows the applications to co-exist in it - ie imagine beacon node, vc and execution client as separate binaries - if I pass the same --data-dir to each of them separately, the outcome should be the same if I run them in a single binary - if I run the single binary, stop it and then run just the beacon node with the same --data-dir, that should "just work".

[arnetheduck]

the consequence of the above is that we want to tie directory structure to "functionality" and not to any particular end-user application (ie it doesn't matter if the user starts a "validator client" as a separate binary or use the integrated beacon validator - it's the "validator functionality" is what guides what the layout looks like - in this sense, it doesn't make sense to have names like "beacon node" or "validator client" as part of the directory structure.

[pedromiguelmiranda]

the consequence of the above is that we want to tie directory structure to "functionality" and not to any particular end-user application (ie it doesn't matter if the user starts a "validator client" as a separate binary or use the integrated beacon validator - it's the "validator functionality" is what guides what the layout looks like - in this sense, it doesn't make sense to have names like "beacon node" or "validator client" as part of the directory structure.

I agree and personally like the direction, and this is the first step towards it:

• Make the procedure generic for all clients (they will be addressed later on a different PR) and removing the hardcoded path "BeaconNode" keeping the same behaviour as before.

Other steps, besides the obvious one of applying the same strategy to other clients still in development phase, is that Nimbus beacon node client is public and users are not aware of the changes proposed (removing the "BeaconNode" path)

A strategy and specially a delivery method need to be defined and tested among all clients. The delivery part is more concerning given that we we need to either warn users using default data directory to move the data manually, or doing it during installation or doing it via code.

Strategies, in my opinion, to be addressed and reasoned about on upcoming PR's