Resolving an infinite loop distributing events to a websocket subscriber

[chrisguidry]

The outward signs of this manifest as the Prefect server not stopping in
response to an interrupt after a websocket subscriber has connected once. The
specific scenario that caused that was:

• Subscriber connects and start listening for events from the server
• The server opens a queue with the distributor and starts the loop to check for
  new events, periodically yielding back control
• If no events ever arrive for that subscriber (due to a restrictive filter or
  just an absence of events), the loop will just continue indefinitely even if
  the subscriber disconnects
• This leads to there being an unfinished task on the event loop, preventing the
  server from shutting itself down cleanly

The ideal solution here would be to send a ping message down the wire to the
client, but we don't have access to those lower-level protocol messages from the
Starlette layer (they are handled by the webserver, like uvicorn in our case).
The solution here is twofold:

1. Actually yield control all the way back to the caller of the stream.events()
   by yielding a None when there's no new event for a while
2. When getting that control passed back to the socket endpoint, it can perform
   a (mildly hacky) test by attempting to receive from the socket (knowing
   that the client isn't expected to send anything); this works as a
   functional "are you still there?" test that we can perform without needing to
   introduce a client-side acknowledgement to the streaming protocol

Fixes #13868

[chrisguidry]

This is unrelated, but I noticed that it looks like the distributor stops immediately after starting. It's just because our start functions aren't supposed to return early