improve USB CDC disconnect/reconnect checking

[dhalbert]

Fixes #3588.

Check for DTR by querying tud_cdc_get_line_state(), and check for tud_usb_ready(). One doesn't need to save state in callbacks this way.

Tested two ways:

• By putting the host computer to sleep, and then waking it up. When sleeping, supervisor.runtime.serial_available becomes falase. After wakeup, the serial connection is restored, and supervisor.runtime.serial_available is True. Interrupting the running program with ctrl-c works properly, and one can get to the REPL.
• Powering the board externally (AC adapter on a Metro M4), and unplugging and replugging the USB cable.

I did try the data/charge-only cable with a switch, but it gives peculiar results. It detects as disconnected and then reconnected when switched, I think because some resistors are added to the data lines to mark the cable as charge-only.

[jepler]

Thank you -- this looks great, much better than what I had come up with! No testing performed.

[tannewt]

Look like this is the same as tud_cdc_connected: https://github.com/hathach/tinyusb/blob/745c15d5b5b7fed5fd8e89cc95b76a56af673a60/src/class/cdc/cdc_device.c#L108

[dhalbert]

Thanks - I'll use this in the alarm PR. I have to change stuff there anyway.

[siddacious]

@dhalbert Apologies if I missed it, but is there a similar ticket for mass storage? It's pretty much expected that when I start using my computer in the morning, if I had a board (Feather M4 for sure, Metro M4 likely, nRF possibly as well) plugged in and running the night before it will run and have CDC working (in the same terminal window but I won't have a CIRCUITPY drive until I reset the board.

[dhalbert]

@siddacious I don't think there is a similar ticket. You can go ahead and open one. It might depend on the host OS.