android: fix network change handling on API levels 24+

[dmytroreutov]

Relates to #12327

PS: Not using android.net.ConnectivityManager.NetworkCallback#onCapabilitiesChanged for API 24+ can also be an issue if capabilities change and user needs to receive updates.

This PR should improve network change detection for API levels 24+.
For example, in case of WI-FI -> Cellular transition and vice versa, NetworkCapabilities will change it's transport, resulting in android.net.ConnectivityManager.NetworkCallback#onCapabilitiesChanged invocation.
We can check, if NetworkCapabilities contain needed capabilities after such transition.

For more detailed network change detection, something similar to this can be done.

[ejona86]

Do we need something more sophisticated? In the Android docs:

Starting with Build.VERSION_CODES.O this method is guaranteed to be called immediately after onAvailable(Network).

So we'll end up doing enterIdle() twice. If an RPC is attempted in between, that may mean we do a DNS request and throw it away, which we might just accept. If we're saying that's okay then at least we should have a comment.

[dmytroreutov]

@ejona86 this is up to debate (maybe).

During my test on a real device adding android.net.ConnectivityManager.NetworkCallback#onCapabilitiesChanged to AndroidChannel was helpful, because network transport switch triggers this method and AndroidChannel can already validate NetworkCapabilities there.

IIRC, switch from Wi-Fi to cellular (when .enterIdle() is finally invoked) will be handled after a couple of seconds with current implementation. Cellular to Wi-Fi is processed much faster.

I can agree that this case is kinda niche and less frustrating than on API levels < 24.
That's why I opened a separate PR and initially doubted it's importance.