staking-miner: remove need of a file to pass the seed

[chevdor]

Currently the seed needs to be passed as a PathBuf pointing to a file containing the seed.

This PR allows to:

• renames --account-seed into --seed
• pass the seed directly as a string (--seed 0x1234...) ⚠️
• pass the seed as string via ENV ( SEED=0x123... staking-miner dry-run) or via .env ℹ️
• pass the node URI as ENV ( URI=wss://... SEED=0x123... staking-miner dry-run) ℹ️

⚠️ Not recommended for safety reasons
ℹ️ Make sure to always prepend your commands mentioning the SEED with a leading space

Those changes make it potentially safer and easier to package the staking miner and use it as a container (prepared in #3682)

[kianenigma]

isn't it a bad practice to pass the seed like that to the command, since it will be saved in all sorts of history files etc.? This is why I initially pref red passing a file in.

Otherwise looks good to me.

[chevdor]

isn't it a bad practice to pass the seed like that to the command, since it will be saved in all sorts of history files etc.? This is why I initially pref red passing a file in.

Totally!
The best recommandation is to pass an ENV, thus this PR. It may be useful however for testers and devs to have a simple way to pass the seed for now. If we want to really harden this, we could totally remove both short and long, effectively forcing the user to pass the seed as a SEED ENV var.

Note that the security still remains in the hand of the user, who can still call the staking miner with (⚠️ do NOT do the following at home, this is bad too!!):

SEED=0x1234... staking-miner ...

Effectively leaving the SEED in the history exactly like it happens calling staking-miner --seed 0x1234...

NOTE: There a little trick if you do not want to leave traces in your history though. The history can be totally disabled but that removes the convenience... or use:

 staking-miner --seed 0x1234... ...
^

instead of:

staking-miner --seed 0x1234... ...

(Notice the barely visible leading space).

I also added .env to the list of ignored files in the repo in this PR. That helps also regarding security as one can then create for dev purposes a .env file with the content:

SEED=0x1234

This file can be loaded manually or automatically. Making a call as staking-miner --uri ws://... dry-run possible, without having to pass the ENV at all.

[kianenigma]

Okay, sounds good to me. Only note is that this will need to be redeployed after the first runtime release that contains this, since the flag has changed. But not a blocker, since a proper upgrade mechanism for staking miner does not exist and is purely manual for now.