fix(tun): eliminate busy-loop CPU spin in networkUpdateMonitor

[bcseputetto]

Replace the single-goroutine event loop with dedicated blocking readers per netlink channel and a ticker-driven emit check, and enlarge the route update channel buffer to absorb large bursts.

Under normal conditions the previous implementation loop selected over route/link/address update channels and coalesced bursts into a single emit() within a 1s window. However, when a large number of netlink route events arrive in a short window (observed: ~5000 routes created at once by a third-party network accelerator), two problems compounded:

1. The route update channel had a buffer size of only 2, causing frequent blocking handshakes between the netlink producer goroutine and this consumer, which is expensive at that volume.
2. An earlier attempt to fix this by non-blockingly draining each channel (select { case <-ch: default: return } in a tight loop) turned into a busy-loop whenever the channel kept refilling faster than it could be drained, pinning a CPU core. CPU profiling confirmed ~28% average core usage over a 30s window, with ~99.9% of cumulative time inside loopUpdate -> drainRoute -> runtime.selectnbrecv.

This change addresses both issues:

• routeUpdate channel buffer increased from 2 to 8192 to absorb known burst sizes (~5000 events) without producer-side blocking; linkUpdate/addressUpdate bumped from 2 to 32 as a smaller margin.
• Removed the single loopUpdate goroutine.
• Added three dedicated reader goroutines (readRouteLoop/ readLinkLoop/readAddrLoop), each doing a plain blocking channel receive and setting an atomic dirty flag. Blocking receive parks the goroutine when idle (no CPU spin) and processes bursts at the channel's natural pace with no polling overhead.
• Added emitLoop, a single goroutine that checks the dirty flag on a fixed 1s ticker and calls emit() via CompareAndSwap, bounding emit() frequency to <= 1/s regardless of event volume.

Behavior change: the previous implementation triggered emit() immediately on the first event after an idle period (leading edge) and coalesced subsequent events within the following 1s window (trailing edge). The new implementation only checks the dirty flag once per second, so a single isolated event may now be observed with up to ~1s of additional latency compared to before. This was considered an acceptable tradeoff given the CPU regression; a leading-edge variant can be added later if the added latency proves noticeable in practice.

No changes to NewNetworkUpdateMonitor, Start()/Close() signatures, Android netlink-banned detection, or the shared emit()/ RegisterCallback()/UnregisterCallback() implementations in monitor_shared.go. emit() continues to be called from a single goroutine only (emitLoop), so no additional synchronization is required downstream.

to fix SagerNet#4440