Proper handling of slow-loris mitigation. #33440

Is your feature request related to a problem? Please describe.
Bug Regression in idle socket handling #24980 may be prevented for all timeout settings, if slow-loris mitigation (eb43bc0) was done properly, and client was notified about server.headersTimeout expiration by closing or discarding the socket.

Describe the solution you'd like
Currently the timeout is passive, i.e., resolved on next event (which may be minutes later, depending on configuration). I propose active timeout event instead, i.e., closing/discarding the connection on timeout expiration. That would send RST or FIN packet to the client and it would also free the resources allocated to the connection.

Describe alternatives you've considered
Is there any? In fact, in rare circumstances the client may ask at the exact time the timeout expires, leading to current behaviour. This is not ideal, but various rare networking and server errors would have comparable probability, thus proper documentation should be sufficient here.
Also I have not tested that ELB would react properly on this solution. But current behaviour is misleading to many IT engineers, as the timeout does not manifest itself immediately, rather it appears as a bug in server/application implementation.