[epic]: revive `ChannelRouter` as the layer 3 within the ln stack

[yyforyongyu]

As of today, the routing package has the following tasks:

1. Handling onchain notifications inside routing/chainview
2. Processing gossip messages via ChannelRouter.handleNetworkUpdate
3. Understanding network topology (CachedGraph)
4. Maintaining a probability graph (MissionControl)
5. Performing pathfinding (findPath)
6. Sending payments (paymentLifecycle)

We need to refine and move some tasks out of the routing package to make ChannelRouter fulfill its promise:

lnd/routing/router.go

Lines 431 to 438 in 26892a2

	// ChannelRouter is the layer 3 router within the Lightning stack. Below the
	// ChannelRouter is the HtlcSwitch, and below that is the Bitcoin blockchain
	// itself. The primary role of the ChannelRouter is to respond to queries for
	// potential routes that can support a payment amount, and also general graph
	// reachability questions. The router will prune the channel graph
	// automatically as new blocks are discovered which spend certain known funding
	// outpoints, thereby closing their respective channels.
	type ChannelRouter struct {

Proposals

A high level summary of proposed changes, each item should have its own issue page to provide the details.

• Similar onchain notifications have been implemented in routing/chainview, chainntnfs and btcwallet/chain. We should instead have a single place deadling with blockchain data, i.e., btcwallet/chain should be the only entrypoint to access chain backends (TODO: add an issue page).

• Fix duplicated gossip handling found in gossip and routing, detailed in [epic]: ChannelDB, Graph, Gossiper and Router separation #8833

• A subservice to handle payments, detailed in [epic]: Payment and Router separation #8834

• TBD: the relationship among the network graph, probability graph and pathfinding - ChannelRouter can be the single entity to interact with, while the probability graph can be a subservice that provides pathfinding.