Unbuffered stdout

[dlech]

Is your feature request related to a problem? Please describe.
Yes. (See pybricks/pybricksdev#16).

Since stdout is buffered, it is possible for the user program to end before all data has been sent over Bluetooth.

This means that connected devices don't know when it is safe to disconnect since even though the program has ended, there still may be more data to receive.

Describe the solution you'd like
When a user program ends, we should be sure to drain the stdout buffer before exiting the MicroPython runtime. This way, we can be sure that when the user program running status flag is set to false that there is nothing left to be received from the stdout stream.

Describe alternatives you've considered
We could also be more like CPython (see below) and drain the stdout buffer during each write. This means that, for example, a print() would always block until everything is sent over Bluetooth. The current behavior, on the other hand, will return immediately from a print() unless the buffer is full.

Additional context
In CPython, there is the -u command line option and corresponding PYTHONUNBUFFERED environment variable to deal with this problem. (Although in CPython the data is always lost instead of just delayed.)

In Python 3.7, stdout was changed so that the text part of it is always unbuffered.

[laurensvalk]

When a user program ends, we should be sure to drain the stdout buffer before exiting the MicroPython runtime. This way, we can be sure that when the user program running status flag is set to false that there is nothing left to be received from the stdout stream.

This should be easier now that we changed when the program running flag is cleared.

[dlech]

Some progress has been made on this on BLE hubs. This still needs additional consideration with regard to blocking/nonblocking in async type programs and with regard to other hub types.

[laurensvalk]

When a user program ends, we should be sure to drain the stdout buffer before exiting the MicroPython runtime. This way, we can be sure that when the user program running status flag is set to false that there is nothing left to be received from the stdout stream.

This was done between 3.3 and 3.5. See #1152 for details.