* write any partial message
* instead of "..." show a sensible (translatable) message
This does slightly lower the amount of data that can be printed,
and makes the exact amount dependent on the language. However, if boot.py
intentionally needs to produce larger amounts of output, it can
deliberately mount the filesystem in RW mode and perform any writes needed.
In that case it's up to the boot.py to choose an appropriate way to
limit the number of writes if needed for the application.
Now, open wifi works on Pico W, so this closes#7438.
For the web workflow it's now OK to either
* specify an empty password string (as before)
* not have the CIRCUITPY_WIFI_PASSWORD key at all (new functionality)
This may help address #7409 if the underlying cause is the deterministic
volume ID. However, not all boards have working urandom (samd21
at least does not) so a couple of fallbacks are attempted when it fails.
I verified that on a pico_w, each `storage.erase_filesystem()` gives
a distinct 32-bit volume ID (pico_w's urandom can never fail)
* Set nonblock on all accepted sockets. Not just ones for user code.
* Close an open websocket if another is accepted.
* Set debug level to INFO rather than DEBUG because DEBUG crashes
on ESP32-S3 USB OTG.
When the USB serial buffer is full, the Ctrl-C code to send
KeyboardInterrupt can't be sent, which creates a problem if you've
pasted code or otherwise filled the buffer and need to recover.
A similar problem affects advanced UIs that interact with CircuitPython
and may send characters when they're unexpected, such as mu when it
tries to move the cursor based on the user clicking on the screen.
The main way forward seems to be to use some kind of message that can
still reach CircuitPython when its internal serial recieve buffer is full.
RS232 defines a "break" signal, in which the transmitting device holds its
data line in the "space" state for many entire character times. This still
exists in the world of USB serial.
This does work, sort of, except that your host computer software will need
to properly handle blocking serial writes; tio can send a break with
the **ctrl-c b** sequence, but this only works if it hasn't yet written
too much data, so it doesn't actually help in most situations :-/
It doesn't need never reset because the status LED is only active
when user code isn't.
This also fixes PWM never reset on espressif so that deinit will
undo it.
Fixes#6223
