FR: Make enode persistent among restarts

[barnabasbusa]

Nimbus-eth1 currently initiates a new enode each time the service is restarted. This is inconsistent behaviour, as all other ELs will keep the enode as long as their db is not wiped, and init a new enode if the db is wiped.

It would be good to write nodekey to disk - probably where the db lives, which could be used as a seed to init the enode.

One way to set this now is using --net-key= but unfortunately this seems to have some bugs among restarts.

INF 2024-10-22 07:28:42.020+00:00 Starting metrics HTTP server               address=0.0.0.0 port=9001
INF 2024-10-22 07:28:42.025+00:00 Writing genesis to DB
INF 2024-10-22 07:28:42.025+00:00 Database initialized                       base="(0xba12b41c973893687480edec78579303aa951e2fd73ae7bb753753ff6d74652b, 0)" finalized="(0xba12b41c973893687480edec78579303aa951e2fd73ae7bb753753ff6d74652b, 0)" head="(0xba12b41c973893687480edec78579303aa951e2fd73ae7bb753753ff6d74652b, 0)"
/root/nimbus-eth1/nimbus/sync/protocol/snap/snap_types.nim(844) main
/root/nimbus-eth1/nimbus/sync/protocol/snap/snap_types.nim(832) NimMain
/root/nimbus-eth1/nimbus/nimbus_execution_client.nim(219) _ZN23nimbus_execution_client3runE3refIN11nimbus_desc26NimbusNodecolonObjectType_EEN6config10NimbusConfE.constprop.0
/root/nimbus-eth1/nimbus/nimbus_execution_client.nim(53) _ZN23nimbus_execution_client14manageAccountsE3refIN11nimbus_desc26NimbusNodecolonObjectType_EEN6config10NimbusConfE
/root/nimbus-eth1/vendor/nim-serialization/serialization.nim(90) _ZN7manager13loadKeystoresE3varIN7manager15AccountsManagerEE6string
/root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/pure/json.nim(516) _ZN4json7X5BX5D_E3refIN4json11JsonNodeObjEE6string
/root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/std/assertions.nim(41) _ZN10assertions16failedAssertImplE6string
/root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/std/assertions.nim(36) _ZN10assertions11raiseAssertE6string
/root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/system/fatal.nim(53) _ZN10assertions8sysFatalE8typeDescIN10exceptions15AssertionDefectEE6string
/root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/system/excpt.nim(345) _ZN6system18rawWriteStackTraceE3varI3seqIN6system15StackTraceEntryEEE
/root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/system/stacktraces.nim(62) _ZN11stacktraces30auxWriteStackTraceWithOverrideE3varI3seqIN6system15StackTraceEntryEEE
Error: unhandled exception: /root/nimbus-eth1/vendor/nimbus-build-system/vendor/Nim/lib/pure/json.nim(515, 9) `node.kind == JObject`  [AssertionDefect]

[arnetheduck]

the enode is a session key - there's no technical reason for it to be permanent, except to make data collection about peers easier - arguably, this could be considered an issue in the other clients.

That said, we should write the temporary key to disk similar to how we do it in eth2 so that scripts and utilities easily can pick it up for running nodes, much like a pid file - in the case a command-line flag is given, we should also read it from disk if it exists so that those that have reason to make the key permanent (such as custom "trusted node" setups or public bootnodes) can do so.