Refactor doEndStream in HCM

The doEndStream in the HttpConnectionManager is somewhat misleading because it is only called for some code paths that result in a stream being shut down (including the happy path).

We should consider refactoring this code to make this easier to understand, perhaps by ensuring that this cleanup code is always called on stream end: this would help centralize any cleanup code, including calling deferred delete.

Another option would be to rename the function to make its intent clearer: it currently tries to figure out if the downstream should be reset and handles updating drain_state_, which is not easily inferable from its current name.