Execution in `asyncio.run` raises stuff

[chrysn]

The current basic examples use the old asyncio.get_event_loop().run_until_complete(main()) idiom rather than the 3.7-ish asyncio.run(main()).

Switching over to the new without adding an explicit await protocol.shutdown() step gives terrifying output like:

Exception ignored in: <function RecvmsgSelectorDatagramTransport.__del__ at 0x7fd8667116c0>
Traceback (most recent call last):
  File "/home/chrysn/git/aiocoap/aiocoap/util/asyncio/recvmsg.py", line 95, in __del__
    self.close()
  File "/home/chrysn/git/aiocoap/aiocoap/util/asyncio/recvmsg.py", line 83, in close
    self._loop.call_soon(self._protocol.connection_lost, None)
  File "/usr/lib/python3.10/asyncio/base_events.py", line 745, in call_soon
    self._check_closed()
  File "/usr/lib/python3.10/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

Rather than making everyone and their dogs do clean shutdowns manually, look into whether async shutdowns can be

• done in a more automatic fashion (probably no async destructors, but look at what's in the finally clause of https://github.com/python/cpython/blob/43bab0537ceb6e2ca3597f8f3a3c79733b897434/Lib/asyncio/runners.py#L40),
• raise a more explicit message about the unclean shutdown of a context, and/or
• provide an async context interface around contexts

[chrysn]

Hunting this down showed that the offenders were just assuming a certain shutdown sequence (destruct the items first then the loop), which are being fixed.

Doesn't change that an asynchronous context manager is due, though.