Improve default user logs

[taxmeifyoucan]

Describe the feature

I understand the client is still under heavy development and the current logging might be suitable for debugging. However it becomes pretty confusing and impractical for a normal usage, i.e. starting the client to sync the network and interacting with it.

I suggest default logs should be cleaned, added some currently missing information and generally improved. Let's look into improvement for actual logging, step by step from client start.

First, when client is starting it prints logs which features are initialized. This is great, but missing some important parts:

• What network/genesis was loaded. E.g. geth first prints the network name if known (`Starting Geth on Ethereum mainnet...) and then whole network config, chainid, hardfork block heights, etc. At least basic info about network params to make sure I am following the correct chain would be great
• Client prints config address but it would be nice to also have some highlights of the actual config options. E.g. Min/max peer count, block gas limit, cache values, metrics disabled/enabled, etc
• Information about connection to a CL client. After a while, reth is looking for peers but doesn't inform me it won't sync without connecting a consensus client (or debug.tip). It should print something like Waiting for CL client, CL required for sync..
  • After successfully connecting to a CL client, it should print that the consensus is connected correctly and maybe Merge transition config
  • There are some confusing logs about CL connection which make it even worse. As a user, I am not sure whether this means the CL client is connected or maybe even included in reth

  INFO Consensus engine initialized
  INFO Engine API handler initialized
  INFO Starting consensus engine
  

  • With RPC http and authenticated Engine API endpoint starting, it should inform user at least about what interface/port is used, e.g. in geth HTTP server started endpoint=127.0.0.1:8551 auth=true prefix= cors=localhost vhosts=localhost
• Default logs about peers are currently logging every event when a peer connects or disconnects. This becomes overwhelming when client starts looking for peers and could be simplified to only printing status every n seconds, again similar to other clients. More verbose info should be printed only if user chooses it.
• I assume at this point sync started but I am not informed about what is happening at all. I can see Executing stage stage=Headers from=0 and then status messages Status connected_peers=1 stage=Headers checkpoint=0 which vaguely suggest that sync is in execution stage (downloading headers now?). I wish to be informed more here to be able to identify the bottleneck, client should print what is actually doing (waiting for minimum number of peers, downloading headers/bodies, executing txs..)
• When client shuts down, it's also important to inform what's happening (received interrupt, graceful shutdown, writing state to db..)

One big improvement could be adding an extra column for log details, similar to other clients. Details like config values, number of peers etc are now printed in a single column with general info. Moving this to a separate column improves readability and allows adding more details when needed. The format could look like:

TIMESTAMP  TYPE  LOG  DETAILS
// output example
2023-04-27T18:38:43.194664Z  INFO Configuration loaded             path=/home/user/.config/reth/sepolia/reth.toml
2023-04-27T18:38:43.194672Z  INFO Opening database                 path=/home/user/.local/share/reth/sepolia/db

This is not necessary, maybe just a subjective convention but suggestions above would benefit of having a separate space for printing extra info.

And last nitpick, the timestamp format seem to be following ISO 8601 but would be more readable in a different format, e.g. DAY|TIME as geth/erigon uses 05-01|11:18:53.911

Additional context

These are some thoughts from my initial client experience and I am sure specifying proper logging takes much more. Please share more suggestions in comments so this issue can be used to keep track of logging improvements.