device: avoid cycle-leaky runtime.SetFinalizer when unnecessary

[bradfitz]

In #65, @lkosewsk reproduced a memory leak seen
in prod with lots of wireguard-go instances being created and
destroyed, where they were still being retained forever due to cycles
in the runtime.SetFinalizer reference graph.

Really we shouldn't be using runtime.SetFinalizer anywhere. But we
still use it on mobile platforms in WaitPool. But those platforms
don't have thousands of tsnet.Server instances coming & going, so this
is a half fix: avoid the finalizer registration on Linux, etc where
the queue doesn't need to be drained and there's no WaitPool
accounting. Just let GC handle it, without adding finalizer cycle
complexity.

Updates tailscale/corp#42776

[sfllaw]

Not a blocker, but if there are cases where we need to drain the queue, would it be safer to use runtime.AddCleanup?

[sfllaw]

💡 Suggestion (non-blocking): Would it be possible to convert this so it uses runtime.AddCleanup, which might also be safer?

Suggested change

	if device.needsInboundQueueFinalizer() {
	runtime.SetFinalizer(q, device.flushInboundQueue)
	}
	if device.needsInboundQueueFinalizer() {
	runtime.AddCleanup(q, device.flushInboundQueue, q.c)
	}

(continued…)

[sfllaw]

⬆️ …continued (non-blocking), I think the flusher only needs a minor refactor?

func (device *Device) flushInboundQueue(c chan *QueueInboundElementsContainer) {
	for {
		select {
		case elemsContainer := <-c:

[bradfitz]

runtime.AddCleanup would work, but really I want to get rid of finalizers entirely (with either mechanism). I'm neutral if people want to switch the iOS/Android builds over to AddCleanup meanwhile, but I think it's kinda a waste of time if the end goal is to remove them entirely. If the old finalizer mechanism is "working" for now, I'd rather not touch it in its final days and just let it be.