Also updated the loggings. This new state will be used in the following
commit.

This prepares the following commit where we now let the fee bumpr
decides whether to broadcast immediately or not.

This commit changes how inputs are handled upon receiving a bump result.
Previously the inputs are taken from the `BumpResult.Tx`, which is now
instead being handled locally as we will remember the input set when
sending the bump request, and handle this input set when a result is
received.

This commit adds a new method `handleInitialBroadcast` to handle the
initial broadcast. Previously we'd broadcast immediately inside
`Broadcast`, which soon will not work after the `blockbeat` is
implemented as the action to publish is now always triggered by a new
block. Meanwhile, we still keep the option to bypass the block trigger
so users can broadcast immediately by setting `Immediate` to true.

Previously in `markInputFailed`, we'd remove all inputs under the same
group via `removeExclusiveGroup`. This is wrong as when the current
sweep fails for this input, it shouldn't affect other inputs.

Also updated `handlePendingSweepsReq` to skip immature inputs so the
returned results are the same as those in pre-0.18.0.

With the combination of the following commit we can have a more granular
control over the bump result when handling it in the sweeper.

After previous commit, it should be clear that the tx may be failed to
created in a `TxFailed` event. We now make sure to catch it to avoid
panic.

This commit inits the package `chainio` and defines the interface
`Blockbeat` and `Consumer`. The `Consumer` must be implemented by other
subsystems if it requires block epoch subscription.

In this commit, a minimal implementation of `Blockbeat` is added to
synchronize block heights, which will be used in `ChainArb`, `Sweeper`,
and `TxPublisher` so blocks are processed sequentially among them.

This commit adds two methods to handle dispatching beats. These are
exported methods so other systems can send beats to their managed
subinstances.

This commit adds a blockbeat dispatcher which handles sending new blocks
to all subscribed consumers.

This commit implements `Consumer` on `TxPublisher`, `UtxoSweeper`,
`ChainArbitrator` and `ChannelArbitrator`.

This commit removes the independent block subscriptions in `UtxoSweeper`
and `TxPublisher`. These subsystems now listen to the `BlockbeatChan`
for new blocks.

This commit removes the hack introduced in lightningnetwork#4851. Previously we had this
issue because the chain notifier was stopped before the sweeper, which
was changed a while back and we now always stop the chain notifier last.
In addition, since we no longer subscribe to the block epoch chan
directly, this issue can no longer happen.

The sweeper can handle the waiting so there's no need to wait for blocks
inside the resolvers. By offering the inputs prior to their mature
heights also guarantees the inputs with the same deadline are
aggregated.

This commit removes the block subscriptions used in `ChainArbitrator`
and replaced them with the blockbeat managed by `BlockbeatDispatcher`.

This commit removes the block subscriptions used in `ChannelArbitrator`,
replaced them with the blockbeat managed by `BlockbeatDispatcher`.

This `immediate` flag was added as a hack so during a restart, the
pending resolvers would offer the inputs to the sweeper and ask it to
sweep them immediately. This is no longer need due to `blockbeat`, as
now during restart, a block is always sent to all subsystems via the
flow `ChainArb` -> `ChannelArb` -> resolvers -> sweeper. Thus, when
there are pending inputs offered, they will be processed by the sweeper
immediately.

To avoid calling GetBestBlock again.

This is needed so the consumers have an initial state about the current
block.

In this commit we start to break up the starting process into smaller
pieces, which is needed in the following commit to initialize blockbeat
consumers.

Refactor the `Start` method to fix the linter error:
```
contractcourt/chain_arbitrator.go:568: Function 'Start' is too long (242 > 200) (funlen)
```

We now put the outpoint in the resolvers's logging so it's easier to
debug. Also use the short channel ID whenever possible to shorten the
log line length.

This commit adds a few helper methods to decide how the htlc output
should be spent.

This commit is a pure refactor in which moves the sweep handling logic
into the new methods.

This commit refactors the `Resolve` method by adding two resolver
handlers to handle waiting for spending confirmations.

This commit adds new methods to handle making sweep requests based on
the spending path used by the outgoing htlc output.

This commit adds checkpoint methods in `htlcTimeoutResolver`, which are
similar to those used in `htlcSuccessResolver`.

This commit adds more methods to handle resolving the spending of the
output based on different spending paths.

We will use this and its following commits to break the original
`Resolve` methods into two parts - the first part is moved to a new
method `Launch`, which handles sending a sweep request to the sweeper.
The second part remains in `Resolve`, which is mainly waiting for a
spending tx.

Breach resolver currently doesn't do anything in its `Launch` since the
sweeping of justice outputs are not handled by the sweeper yet.

This commit breaks the `Resolve` into two parts - the first part is
moved into a `Launch` method that handles sending sweep requests, and
the second part remains in `Resolve` which handles waiting for the
spend. Since we are using both utxo nursery and sweeper at the same
time, to make sure this change doesn't break the existing behavior, we
implement the `Launch` as following,
- zero-fee htlc - handled by the sweeper
- direct output from the remote commit - handled by the sweeper
- legacy htlc - handled by the utxo nursery

This commit breaks the `Resolve` into two parts - the first part is
moved into a `Launch` method that handles sending sweep requests, and
the second part remains in `Resolve` which handles waiting for the
spend. Since we are using both utxo nursery and sweeper at the same
time, to make sure this change doesn't break the existing behavior, we
implement the `Launch` as following,
- zero-fee htlc - handled by the sweeper
- direct output from the remote commit - handled by the sweeper
- legacy htlc - handled by the utxo nursery

When calling `NotifyExitHopHtlc` it is allowed to pass a chan to
subscribe to the HTLC's resolution when it's settled. However, this
method will also return immediately if there's already a resolution,
which means it behaves like a notifier and a getter. If the caller
decides to only use the getter to do a non-blocking lookup, it can pass
a nil subscriber chan to bypass the notification.

A minor refactor is done to support implementing `Launch`.

This commit makes `resolved` an atomic bool to avoid data race. This
field is now defined in `contractResolverKit` to avoid code duplication.

In this commit, we break the old `launchResolvers` into two steps - step
one is to launch the resolvers synchronously, and step two is to
actually waiting for the resolvers to be resolved. This is critical as
in the following commit we will require the resolvers to be launched at
the same blockbeat when a force close event is sent by the chain watcher.

We need to offer the outgoing htlc one block earlier to make sure when
the expiry height hits, the sweeper will not miss sweeping it in the
same block. This also means the outgoing contest resolver now only does
one thing - watch for preimage spend till height expiry-1, which can
easily be moved into the timeout resolver instead in the future.

This commit moves the creation of the spending notification from `Start`
to `newChainWatcher` so we subscribe the spending event before handling
the block, which is needed to properly handle the blockbeat.

To prepare for the blockbeat handler.

We now start notifying the blockbeat from the ChainArbitrator to the
chainWatcher.

This way the log lines are shorten.

This commit adds a new method to enable us resending the blockbeat in
`ChainArbitrator`, which is needed for the channel restore as the chain
watcher and channel arbitrator are added after the start of the chain
arbitrator.

To prepare the next commit where we would handle the event upon
receiving a blockbeat.

We need to check `dispatched` before sending conf details, otherwise the
channel `ntfn.Event.Confirmed` will be blocking, which is the leftover
from lightningnetwork#9275.

Starting from this commit, we begin the process of flattening the
multi-hop itests to make them easier to be maintained. The tests are
refactored into their own test cases, with each test focusing on testing
one channel type. This is necessary to save effort for future
development.

These tests are also updated to reflect the new `blockbeat` behavior.

This commit simplfies the test since we only test the preimage
extraction logic in the htlc timeout resolver, there's no need to test
it for all different channel types as the resolver is made to be
oblivious about them.

Also remove unused code.

…eUtxos`

Also flatten the tests to make them easier to be maintained.

The method `AssertActiveHtlcs` is now removed due to it's easy to be
misused. To assert a given htlc, use `AssertOutgoingHTLCActive` and
`AssertIncomingHTLCActive` instead for ensuring the HTLC exists in the
right direction. Although often the case `AssertNumActiveHtlcs` would be
enough as it implicitly checks the forwarding behavior for an
intermediate node by asserting there are always num_payment*2 HTLCs.

We have two sources which can call `handlePacketSettle`, either through
the link's `<-s.htlcPlex`, or the `<-s.resolutionMsgs`, which means the
`closeCircuit` could be call twice. Previously we already caught this
case inside `closeCircuit`, in that we would return a nil circuit upon
seeing `ErrUnknownCircuit`, indicating the circuit was removed. However,
we still need to account the case when the circuit is being closed,
which is now fixed as we will ignore when seeing `ErrCircuitClosing`.

In a rare case when the critical log is triggered when using postgres as
db backend, the `payment` could be nil cause the server is shutting
down, causing the payment fetching to return an error. We now cache its
state before fetching it from the db.

This commit adds a new flag to shuffle all the test cases before running
them so tests which require lots of blocks to be mined are less likely
to be run in the same tranch.

The other benefit is this approach provides a more efficient way to
figure which tests are broken since all the differnet backends are
running different tranches in their builds, we can identify more failed
tests in one push.

To make sure each run is shuffled, we use the action ID as the seed.

Prepares the upcoming refactor. We now never call `ht.Alice` directly,
instead, we always init `alice := ht.Alice` so it's easier to see how
they are removed in a following commit.

This commit removes the usage of the standby nodes and uses
`CreateSimpleNetwork` when applicable. Also introduces a helper method
`NewNodeWithCoins` to quickly start a node with funds.

This commit removes the standby nodes Alice and Bob.

Since we don't have standby nodes anymore, we don't need to close the
channels when the test finishes. Previously we would do so to make sure
the standby nodes have a clean state for the next test case, which is no
longer relevant.