Whether we should let the aux bandwidth manager decide what the
bandwidth of a channel is should also depend on whether the HTLC is a
custom HTLC, not just the channel.
This commit adjusts the backwards compatability test in 2 ways:
1) we first set up the bitcoin backend before waiting for our network
nodes to start. This is so that the nodes can sync to chain and
become fully active during the `wait_for_nodes` call.
2) Then, in the `wait_for_node` helper, we use the status server
response to determine if a node is ready instead of just waiting for
`GetInfo` to return a response. This is because waiting for
SERVER_ACTIVE is a more accurate signal that the node is ready to
receive RPC calls.
The itest framework now handles the closure of any channels opened
during the test and so we dont need to manually close them. The manual
closure code in the route blinding tests were resulting in the
occasional test flake.
In order to get more precise bandwidth reports, we also need to provide
this method with the latest htlc view. Since aux data is committed to in
the channel commitment, some uncommited HTLCs may not be accounted for,
so we need to manually provide them via the HTLC view.
Ensure shutdown assertions through log inspection are only performed
when the harness node has an active log file handle. This avoids
errors during shutdown when log file output is disabled.
For legacy payments, the hash field will be nil, and we need to use the
payment identifier instead. We have multiple ways to fix this:
A trivial solution is we can simply call `sharder.GetHash` in
`collectResult`, and pass this hash to `attempt.Circuit()`, which ends
up multiple methods taking the hash. This is bad as it's confusing why
the methods of `HTLCAttempt` need to take another hash value, while
itself already has the info via `HTLCAttempt.Hash`. We don't want an
exceptional case to influence our main flow.
We can then patch the field `HTLCAttempt.Hash`, and set it to the
payment hash if it's nil, which can be done in `collectResult`. This is
also less optimal as it means every htlc attempts, either legacy or not,
now need to bear this context.
The best way to do this is to patch the field in
`reloadInflightAttempts`. As we are sure any new payments made won't be
legacy, and the only source of legacy payments comes from reloading
existing payments.
