Register the kindness network callback per the Wi-Fi pref

[munzzyy]

Follow-up to 98a0cf3 (#1798). Filtering the network callback to TRANSPORT_WIFI fixed Wi-Fi being ignored while tor's VPN is active, but the "only when on Wi-Fi" switch in the kindness config sheet is still there and can be turned off. With it off:

• on a cellular-only connection, onAvailable never fires (the request only matches Wi-Fi networks), so network events never start the proxy and the notification sits at "starting"
• when Wi-Fi drops while cellular stays up, onLost stops the proxy and no event restarts it until Wi-Fi comes back

The limitSnowflakeProxyingWifi() && !hasWifi check in onAvailable also can't do anything under the filter, since every network it sees is Wi-Fi.

This keeps the Wi-Fi-filtered registration when the pref is on, so the VPN fix stays, and goes back to registerDefaultNetworkCallback when it's off, the single-tracked-network behavior this handler was written for. The service restarts when the config sheet changes a setting (the KEY_CONFIG_CHANGED listener in KindnessFragment double-toggles the switch), so the registration always matches the pref. onDestroy's unregisterNetworkCallback covers both registration paths.

Compiles and the unit tests pass. I don't have a cellular device to hand, so a quick check on hardware with the Wi-Fi switch off would be a good sanity pass.

[bitmold]

I will look into this soon, thank you

[bitmold]

This looks good with my testing. I don't like how which callback is used is tied to reading a value in the Service's onCreate().

Like you said,:

This keeps the Wi-Fi-filtered registration when the pref is on, so the VPN fix stays, and goes back to registerDefaultNetworkCallback when it's off, the single-tracked-network behavior this handler was written for. The service restarts when the config sheet changes a setting (the KEY_CONFIG_CHANGED listener in KindnessFragment double-toggles the switch), so the registration always matches the pref. onDestroy's unregisterNetworkCallback covers both registration paths.

I don't like how switching that preference switch (for limiting to WiFi only) restarts the Service and allows the onCreate() logic you fixed here to work. In an ideal world, these things (the UI, the service, preference changes) wouldn't all be so tightly coupled.

Anyway, thank you for this work. This is a big big help.

[munzzyy]

Thanks for merging it. Agreed on the coupling. Reading the pref in onCreate and relying on the service restart to re-register works with the existing wiring rather than fixing it. The cleaner path is reacting to the pref change directly instead of bouncing the whole service, but that is a bigger change than this bug needed. I am happy to take a run at decoupling it as a follow-up if you think it is worth doing.