wait-for-disconnect and then wait-for-device

[jiyongp]

Previously, right after we do adb reboot, we immediately executed adb wait-for-device. This is problematic because the device may still be in
the process of shutting down (shutdown itself is taking some time), in
which case adb wait-for-device would immediately return, giving a
false signal that the reboot was finished.

Fixing this issue by firstly waiting for the adb connection to be lost
(via adb wait-for-disconnect) and when executing adb-wait-for-device.

Note that other test hardness like tradefed already has had this. ex:
https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/main/src/com/android/tradefed/device/NativeDevice.java#4023

Test: tox passed

---

This change is 

[jiyongp]

Please note that this isn't specific to virtual devices though this time it was manifested in cf_wear. For any Android device, we shouldn't assume that adb reboot will immediately cut the adb connection. The connection is cut only after adbd process in the device is killed and the killing of the process takes some time (though in most cases it's very short, but it never is 0).

[xpconanfan]

Since the problem is related to timing, what if the device immediately disconnected before the cmd wait-for-disconnect finished, we'd be stuck at wait-for-disconnect for a while until timeout?

[jiyongp]

Since the problem is related to timing, what if the device immediately disconnected before the cmd wait-for-disconnect finished, we'd be stuck at wait-for-disconnect for a while until timeout?

No. It returns immediately if the device is already disconnected.

[xpconanfan]

I don't think this logic belongs in the context handler here.
There's no guarantee that the custom logic's last step is to immediately cause the device to go offline.
Or, in other words, the user logic in the handler context should ensure the device has gone offline before proceeding.

So this cmd can be easily done in the user logic.