[HttpFoundation] MongoDbSessionHandler::read() now checks for valid session age

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | no
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

As discussed with @jmikola: 
- It's a bugfix - expired sessions should never be read
- Therefore should be merged into 2.3 LTS
- TODO: Modify the behavior to match the PDO adapter
- TODO: Add a precise description of the behavior to the manual

-- old description below --

This patch can be seen as either bugfix or feature, though it's probably more on the feature-side. 

Currently a session will be returned by `read()` even if it's already older than `gc_maxlifetime`. If `gc_maxlifetime` is used for timing out sessions and a low gc-ratio is in place there is a high chance the session stays alive for a longer time than wanted. The manual describes the current limitations of `gc_maxlifetime` correctly at http://symfony.com/doc/current/components/http_foundation/session_configuration.html#session-lifetime.

But since the modification timestamp is stored in MongoDB anway, we can actually use it to only return "valid" session-data as does the [PdoSessionHandler](https://github.com/symfony/HttpFoundation/blob/2.7/Session/Storage/Handler/PdoSessionHandler.php#L518)








> Ignoring PHP's timezone is probably a bug. But that is located in ext-mongo.

I would disagree. The BSON date type is specified as:

> UTC datetime - The int64 is UTC milliseconds since the Unix epoch.

In your gist, `strtotime()` happens to respect PHP's timezone, as does `date('c')` when you print out the dates later; however, when printing the date on the way out of the database, you're ignoring the original timezone from the `tz` field. PHP will simply use the UNIX timestamp from the MongoDate and render it in the default timezone. This is why the time offsets of the three records are still staggered (0, +2, and +1 respectively). Does that make sense?