Fixes broken Keep-alive: Persist keepalive_timeout between requests on same stream

[matthewbjones]

See #540
See #447

Basically, for HTTP/1.x, the current implementation of the "keep alive" logic is broken and does not function as intended. Although it is possible to modify the "keep alive" value during the HTTP request lifecycle, if the existing stream is kept open and re-used, the request loop creates a fresh HttpSession, with no information from the prior HTTP request, and reverts back to using an infinite-time keepalive. This results in issues if the client never disconnects (and waits for the server to disconnect), resulting in the problems outlined in #447, #540, etc.

This PR attempts to solve this issue by finding the minimal changes required so that the stream re-use event loop has some state information from the previous request. It does this by introducing the concept of ProcessResult, which wraps the existing Option<Stream> that the existing HTTP lifecycle already had, but then provides a mechanism to then "persist" some HTTP session settings via PersistentSettings

In this PR, the only thing being persisted is the session's keepalive_timeout, however, I do believe it would also make sense to also persist read_timeout and write_timeout, as these too also get reset after each request over the same connection/stream.

I can continue to work on this to add in support for read_timeout and write_timeout, but wanted to first run this current approach by the Pingora team for some feedback, before I spend too much time going with an approach that would not be accepted. I went with the approach of solving for the multi-request-same-stream state persistence within HttpServerApp, since the outer request loop engine ServerApp does not provide a method for multi-request state, and didn't want to introduce the concept at that higher level if the only thing that cares is HTTP servers doing HTTP/1.x.