Don't save the session before $response->send()

Problem/Motivation

The BigPipe patch until this issue was unable to deliver the "messages" block — or really, anything that depends on the session. This hugely limits what BigPipe (and other placeholder strategies) can do.

The cause:

the 'messages' block does not play nicely with the session handler in the stage where BigPipe runs

And from IRC:

[2015-09-01 11:23:48] <WimLeers> The messages block works fine with BigPipe? I don't see why it wouldn't.
[2015-09-01 12:19:52] <Fabianx-screen> WimLeers Messges block won't work with BigPipe as the session is shutdown already - somehow - likely bug in session handler.

I just found the root cause of that bug.

The Session middleware does this after it has passed on the request to the HTTP kernel:

    if ($type === self::MASTER_REQUEST && $request->hasSession()) {
      $request->getSession()->save();
    }

Note that this happens before $response->send() happens, and thus before BigPipe streams the response. Which means that any changes to the session (such as messages having been shown and therefore removed from the session's data) that happen while BigPipe is rendering placeholders are lost.

Now, \Symfony\Component\HttpFoundation\Session\SessionInterface::save() has the following documentation:

    /**
     * Force the session to be saved and closed.
     *
     * This method is generally not required for real sessions as
     * the session will be automatically saved at the end of
     * code execution.
     */
    public function save();

Note how it says it's not required to be called.

Then if we do some archaeology to figure out why this is being called in the Session middleware, then we find #2229145: Register symfony session components in the DIC and inject the session service into the request object introduced this and at #30.5 it was asked to document why we're only saving the session for the master request, to which the answer was:

Well, I frankly do not know. This is what Symfony does in its SessionListener. Session is as global as something can be in PHP, so there is not much of a point dragging that through the request stack?

Therefore we can simply remove this.

Proposed resolution

Remove the Session::save() call in the Session middleware.

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Data model changes

None.