the h2c was relying heavily on rewriting connection options to only allow the first request to upgrade; this changes by instead changing the parser on first incoming request, so that if it's upgrade and contains the header, blocks the remainder until the upgrade is successful or not, and if it's not reverts the max concurrent requests anyway
there was a long-standing buggy workaround, whereas in stream-mode, when
there was no response yet to query from, a synchronous request would be
fired. This would break when under event streams, so we had to document
this as "make sure that...".
This fixes it by implementing a general session API convention, which
separates the step of sending the requests, from waiting for its
receival. And, given that the request knows when the response is
available, we can actually "tick until response".
This might be used in the future to refactor the way we handle the
responses, which buffer the full payload by default, instead of reading
from the connection at will.
By setting the h2c protocol handler, the rest became much simpler.
Formatting the upgrade request is a matter for the sub-plugin.
Therefore, the specific h2c request upgrade headers are built-in there.
It was observed that, during a request done via a DoH resolve, the
resolver connection is left in the selector, despite already having
resolved the name, until the whole transfer is done. This is
inefficient, as we're not expected to use it again.
Fixed by improvinng the interest calculation of an HTTP/2 connection; if
the connection doesn't have anything to write. and there aren't any
inflight streams nor pings, connection won't be listened on.
