'expire_after' option on session forces session creation on each and every action

Fotos is correct; the fix for #4938 does not resolve this issue.

Let me see if I can sum up the current situation, which I believe has grown out of two conflicting goals:

1) We want to load session data from the session store only when the session is accessed.
2) When we're using the :expire_after option, we want to keep the user's session cookie expiration date fresh -- so, for example, if we've set session cookies to :expire_after => 2.weeks, then every time the user requests a page in our app, we want to reset the expiration date on the cookie to 2 weeks from right now.

We attempt to accomplish the first goal with lazy-loaded sessions, but we undermine ourselves on the second goal, by loading the session on every request when the expire_after option is set. That is, when the expire_after option is set, sessions are created/loaded all the time, and lazy loaded sessions are effectively disabled. So, as it stands, our desire to keep the session cookie expiration date fresh is overriding our desire to load session data only when we need it.

This lazy-loading-thwarting expire_after behavior was introduced in commit 2ae8d307, and, honestly, I would like to see it removed, such that sessions are always loaded lazily, and the cookie expiration date is only freshened when the session is accessed. I think this behavior would be reasonable and expected -- expire_after sets a date in the future after which an unused session effectively expires. If the session has not been accessed, then it has not been used, and so there's no reason to reset its expiration date.

Since this is a relatively straightforward change to make and test, I went ahead and did so. The patch (for master) is attached. If folks agree with it, then I would be happy to see it applied.

(Alternatively, we could try to be more clever -- for instance, perhaps we treat the cookie store differently than the other stores, since it is less costly with the cookie store to create and load sessions. Or maybe we only load the session and reset the expiration date for an existing session (where we assume a session exists if a session cookie was included in the request) but not for a nonexistent session. And in the existing session case, we could conceivably reset the expiration date without loading anything from the server-side store, by simply sending back in the response exactly the cookie that was sent in the request, only with a new expiration date. This doesn't seem too weird, and I would not mind exploring this approach if others think the extra effort and complexity would be worthwhile. But the simple change I've submitted seems good to me.)