Rewrite request handling using futures (promises)
The event loop is currently asynchronous, but single-threaded, a bit like JavaScript. Our queue draining and request handling itself is however still synchronous in that it receives input and control does not go back to the event loop or to handling the next request until that request is fully handled and a response has been generated.
We can rewrite this to use futures (or promises). This future would resolve to a response eventually, which will then be sent back.
The advantage would be that operations that need to wait for other things, such as a response to a request they need from the client before being able to continue, can immediately return a future, so other requests can be handled in the meantime.
Another advantage would be that this paves the road a bit for offloading tasks to separate processes or threads.
This will likely have unintended side effects, however, as we currently expect requests to be executed in a given order (which a server may do, according to the specification) and give certain events special priorities. We have to ensure that this is still the case when things start becoming asynchronous.