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

| Q             | A
| ------------- | ---
| Bug fix?      | yes/no
| New feature?  | yes/no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | no
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

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)









I believe there is a bug with the current code where `read()` may return an expired session (if `gc()` is not invoked).

If we compare this to PdoSessionHandler, its `doRead()` method checks the timestamp and lifetime values *after* selecting the record from the database. If the INI value is changed, I think the correct behavior would be to respect the original lifetime from the session. I suppose it would be updated when we next wrote the session back to the database.

Currently, the MongoDB handler only stores lifetime indirectly in a calculated expiry field (useful for the TTL indexing). To properly fix this, I think we may need to store the lifetime in a new field at all times.