the previous patch was only considering the current inflight request and the pending requests, but in a scenario where multiple requests may have been buffered and considered in theory in-flight, this information would pass by, leading to a busy loop
this causes a very subtle bug where, in a multifiber scenario, when the last active stream is closed and the connection is checked-in, only to be checked out later and pinged for liveness, it may get caught in the termination flow of a session, which will try to deactivateconnections from the selector; given that only inflight requests were taken into account, it'd get deactivated and checked in, which would mess with the fiber which was actively using it
this fixes it by considering the ping state in the decision on whether the connection should be deactivated; when having an inflight ping, keep it open and in the selector
this is used downstream to inform the selector (via IO interest calculation) whether the connection should wait on events for the current fiber (i.e. the connection should be used for requests of the current fiber, or DNS requests for the connection of such requests must be pending)
do not check buffer before going to the parsers, which also take that account
for http2, use the http2 connection send buffer (instead of the connection buffer) to figure out whether it's waiting on a WINDOW_UPDATE, which is more correct and efficient
on http1, the logic is the same, but the code is simplified, as the checks become the same regardless of whether request or @requests.first is picked up
the decision to use IO.select was based on the number of selectables, however only on select_many the actual selectables would be prefiltered before being passed to it, in some cases meaning that only one descriptor would be passed to IO.select (instead of IO#wait_readable or the like)
in fiber-scheduler frameworks, this meant going a potentially more inefficient route needlessly, such as in async, where IO.wait_readable and the like are performed using epoll or kevent, whereas IO.select calls are executed in a background thread
in a normal situation this would not happen, as events on a resolver would be dealt one at a time, but in a fiber-scheduler environment like async, the first query could be buffered in the 1st fiber switch, the second could then be enqueued on 2nd, then flush buffer and fiber switch on read, and a third query would then enter a corrupt state where, due to the buffer having been flushed on the 2nd fiber, write the 3rd query before receiving the second one, and messing up the pending query bookkeeping, making the fiber then block (due to DNS query never returning back) and expose that as an empty interest registration from some other connection on the selector
this is fixed by using @timer as a proxy for knowing that a given DNS query has been flushed but is still waiting on a response (or an eventual retry)
the routine was using #fetch_response, which may return nil, and wasn't handling it, making it potentially return a nil instead of a response/errorresponse object. since, depending on the plugins, #fetch_response may reroute requests, one allows to keep in the loop in case there are selectables again to process as a result of it
when coupled with the retries plugin, the exception is raised inside send_request, which breaks the integration; in order to protect from it, the proxy plugin will protect from proxy connection errors (socket/timeout errors happening until tunnel established) and allow them to be retried, while ignoring other proxy errors; meanwhile, the naming of errors was simplified, and now there's an HTTPX::ProxyError replacing HTTPX::HTTPProxyError (which is a breaking change).
when a proxied ssl connection would be lost, standard reconnection wouldn't work, as it would not pick the information from the internal tcp socket. in order to fix this, the connection retrieves the proxied io on reset/purge, which makes the establish a new proxyssl connection on reconnect
