A recent change in this area of the codebase refactored some code to
make way for the deprecation of the streaming multi-route `SendToRoute`
method. Along the way, it removed the parsing of the `PaymentHashString`
field for the sync `SendToRouteSync` which is meant to be used via the
REST interface. In this commit, we fix this by populating _both_
`PaymentHash` and `PaymentHashString`. This is OK, as
`extractPaymentIntent` will check both values to extract the hex-encoded
payment hash if it's specified.
Because the integration tests are already long-running, it is preferable to
add testing for the RPC channel update subscription to an existing test rather
than adding additional tests.
This function will be used in the switch to retrieve the channel point for a link,
allowing the switch to retrieve individual channels from the database.
This commit introduces the channel notifier which is a central source
of active, inactive, and closed channel events.
This notifier was originally intended to be used by the `SubscribeChannels`
streaming RPC call, but can be used by any subsystem that needs to be
notified on a channel becoming active, inactive or closed.
It may also be extended in the future to support other types of notifications.
`createRPCChannel` is used by the `listchannels` RPC call and will be
used by `subscribechannels` as well.
`createRPCClosedChannel` is used by the `closedchannels` RPC call and
will also be used by `subscribechannels`.
This is used by the `listchannels` RPC call and will be used by
`subscribechannels` as well. Its purpose is to mitigate code duplication
between the two RPC calls.
To ensure a call to ConnectToPeer doesn't block the agent from
shutting down, we'll launch it in a non-waitgrouped goroutine, that
will signal when a result is returned.
Previously we would use the best known height as height hint, which
could lead to using a height hint above the actual block it confirms,
hence losing track of the confirmation.
In this commit, we modify the way we attempt to locate the our channel
peer to establish a persistent connection on start up. Before this
commit, we would use the channel policy pointing to the peer to locate
the node as it's embedded in the struct. However, at times it's
currently possible for the channel policy to not be found in the
database if the remote nodes announces before we finalize the process on
our end. This can at times lead to a panic as the pointer isn't checked
before attempting to access it.
To remedy this, we now instead use the channel info which will _always_
be there if the channel is known.
