Consider use a more advanced tracing library (e.g. tokio-rs/tracing) for logs

[contrun]

We current use https://docs.rs/log/latest/log/ for logs. As more and more debug logs are accumulating, this can quickly become unwieldy. The major pain points for me is

1. No structured logging support. There are currently many logs like

https://github.com/nervosnetwork/cfn-node/blob/11f710bafc809af779441daf1eb73b1b603e185c/src/ckb/channel.rs#L1956-L1959

scattered around the code base, with tokio-rs/tracing, we can easily convert the above statement to

        debug!(
            commitment_number = commitment_number,
            commitment_point = commitment_point,
            "Obtained commitment point for commitment number",
        );

The major benefit of above statement for now is enhanced search-ability while debugging. Structured logging may have other benefits in the future.

2. No context. No application level calling stacks. Here are two examples why these things might be useful.

• There is now a hack to differentiate different cfn-node instances running in the same terminal. It would be great if we can just propagate these kind of context easily. https://github.com/nervosnetwork/cfn-node/blob/11f710bafc809af779441daf1eb73b1b603e185c/src/main.rs#L23-L29

• Currently we need to trace back to the origin of one error with some toils. For example, I find myself have to sift through all the logs to find out the caller of function get_remote_commitment_point to find out what triggered the index out of bound error. I reckon spans can be quite useful in this case. https://github.com/nervosnetwork/cfn-node/blob/11f710bafc809af779441daf1eb73b1b603e185c/src/ckb/channel.rs#L1964-L1975