Improve listpeers handling diagnostics

[ksedgwic]

This PR addresses (but does not fix) #214

We don't have enough information about the nature of the unexpected handling error:

• Improve the ConstructedListpeers handling diagnostics.
• Hopefully this pattern will prove useful in future debugging improvements.

[vincenzopalazzo]

wondering if this is due some channels that are null?

otherwise LGTM

[vincenzopalazzo]

listpeers should not have the channels anymore, so we may want drop it?

[ksedgwic]

So this is a ConstructedListpeer which is a "compatibility struct" invented by me to make the conversion easier. Basically I convert the return from listpeerchannels into what the old listpeers output used to look like, so the consumers do not need to invert their loops and logic.

[ksedgwic]

wondering if this is due some channels that are null?

I think so too, specifically I'm guessing that they have channels which don't have status fields. The code look for status w/o checking to see if the field exists.

Based on prior experience these poorly formed channels might exist early in their lifecycle, before they are confirmed.

I expected to see the errors during initial channel creation and didn't in my most recent run, so there is some chance I don't understand the mechanism completetly though.

[vincenzopalazzo]

Mh these are good point, but the status should always exist otherwise there is a bug in cln, I will try to look inside the codebase in this week

[vincenzopalazzo]

LGTM