Implement query packet pending command

[mzabaluev]

Add a hermes query packet subcommand that shows all pending packets for a channel at both ends.

Originally posted by @ancazamfir in #1834 (comment)

[mzabaluev]

I need some more clue on how the pending packets should be represented in the output of the command.

If this command is to display packets pending at both ends of a channel, should the output:

1. provide a structured representation of the queues at each end as named fields; or
2. dump all packets in a flat list, but include the information about the chain the packets are pending on?

Cc @mircea-c @ancazamfir

[ancazamfir]

I think 1. @mircea-c should have a big say here.
For me, the problem with the current CLIs is that a lot of concentration is required to figure things out.
I usually do:

• query local commitments
• query unreceived packets on counterparty
• query unreceived acks locally

And obtain something like this:

pending_local_commitments: [1, 2, 3]
not_received_on_counterparty: [2, 3]
received_on_counterparty_but_not_acked_locally: [1]

Then repeat the same for the other side. It would be nice to have ^ with one CLI.

The other problem with the current CLIs is with the formatting, we display one sequence per line. When there are tens/ hundreds of packets the output is pretty much useless without some extra parsing. Something like this would be nice for human eyes:

pending_local_commitments: [100-200, 202, 207]
not_received_on_counterparty: [150-200, 202, 207]
received_on_counterparty_but_not_acked_locally: [100-149]

But then probably not good for tooling/ automation.

[mzabaluev]

@ancazamfir So it seems that in addition to the directionality information, the output would classify pending packets by kind. Should there be any details on the packet items themselves, or just IDs, possibly collated as you suggest?

But then probably not good for tooling/ automation.

We've got the JSON mode for that, so we can make it nice for the Debug impl.

[ancazamfir]

@ancazamfir So it seems that in addition to the directionality information, the output would classify pending packets by kind. Should there be any details on the packet items themselves, or just IDs, possibly collated as you suggest?

just IDs imo. collated would be great!

But then probably not good for tooling/ automation.

We've got the JSON mode for that, so we can make it nice for the Debug impl.

perfect!

[mircea-c]

I think what @ancazamfir suggested is excellent. It gets my vote.

[mzabaluev]

pending_local_commitments: [1, 2, 3]
not_received_on_counterparty: [2, 3]
received_on_counterparty_but_not_acked_locally: [1]

@ancazamfir As the first set is strictly a union of the other two, do we need to display it? Perhaps in text mode, but for JSON it would be redundant information.

[mzabaluev]

I'm implementing this as another subcommand of query packet, tentatively named pending as suggested by @romac. This will show a structured summary of unreceived-acks and unreceived-packets queries in both directions, where each commitment set is assigned to the channel end where the commitments are pending.

Meanwhile, we could continue redesigning the CLI so that this new command supersedes the more elementary commitments, unreceived-acks, and unreceived-packets, with some flags to select portions of the information if needed.

[ancazamfir]

@ancazamfir As the first set is strictly a union of the other two, do we need to display it? Perhaps in text mode, but for JSON it would be redundant information.

sure, we can have that in text mode.