lnrpc: expose commitment type on pending open and waiting close channels

[joostjager]

Small addition so that users with waiting close channels can find out whether it makes sense to try to bump the commitment fee.

Added commit type to pending open channels as well as it was just a single line.

Pending close channels take their info from the close summary, which unfortunately doesn't provide easy access to the commit type.

[cfromknecht]

LGTM after rebase

[carlaKC]

Nice!

[joostjager]

Realizing now that for the pending close channels, the default commitment type will be displayed always. Need to fix that in some way.

[joostjager]

The problem is that the PendingChannel proto message is used in every pending channel category. Options:

1. Add an 'unavailable' commit type and return that for the pending close channels
2. Lift commit type out of the common PendingChannel message into only pending open and waiting close. Works, but it can be argued that the commit type shouldn't really reside at that level.
3. Make commit type available for pending close channels. A lot of work because the force close summary doesn't contain this info now. And still for existing channels, we wouldn't know the value of that field.

@carlaKC @cfromknecht prefs?

[carlaKC]

1. Add an 'unavailable' commit type and return that for the pending close channels

I think this would be my preference, moving the field (2) doesn't make sense, and (3) is more work than it's worth for a rpc change.

#4111 added some information to pending channels using the historical channel bucket, I think it's ok to do the same here:

• pending_open_channels + waiting_close_channels: ok, have db channel
• pending_closing_channels + pending_force_closing_channels: can get from historical channel, if present, otherwise leave as unknown

[cfromknecht]

Yes I agree with @carlaKC, i think leaving as unknown is likely the best option at this point. Several of our recently added rpc fields take this approach when we can't backfill information.

[joostjager]

unknown or is unavailable better?

[joostjager]

Stuck with UNKNOWN. Unfortunately it became UNKNOWN_COMMITMENT_TYPE because proto requires global enum values to be unique. Because this enum is shared between messages it needs to be global.

[joostjager]

Nice to see the historical bucket being used now. The originally intent was for anchors, but in the end we didn't need it.

[joostjager]

@cfromknecht final check whether there is a better solution for the proto enum

[cfromknecht]

LGTM!