SessionManager improperly abstracts Symfony's Session Component

Problem/Motivation

The upgrade to Symfony 3.4 introduced the use of the SessionProxyBag for any bags within the session system. (Found in this commit, Thanks to Tim Plunkett): https://github.com/symfony/http-foundation/commit/d9625c8abb907e0ca2d750...

Our usage of the SessionManager often results in code like this:

$this->sessionManager->getBag('attributes')->set('foo', 'bar');

This would have been fine and worked in 8.4.x and earlier, but in 8.5 you must now:

$this->sessionManager->getBag('attributes')->getBag()->set('foo', 'bar');

This is because getBag('attributes') used to return an AttributesBag and now returns a SessionProxyBag which wraps the AttributesBag. This is super confusing for a number of reasons, but most importantly, our session handling appears to be a strange "Drupalism" of an abstraction around most of the components Symfony provides without directly using the paradigm they expect. I've not dug in enough to know all the nuance on this, but this was definitely an API break for us because of HOW we use it. Also, worth pointing out that the expected return values make both sets of code above completely unsafe without a ton of additional type checking.

Proposed resolution

We might want to look at how we handle sessions in general and come up with a longer term solution, but for the foreseeable future, we should probably change the getBag() implementation on SessionManager today to identify when we're dealing with a SessionProxyBag and return the bag it's wrapping. This would have completely prevented me from running into this problem. (Again, thanks to Tim for the suggested fix there).

Remaining tasks

Determine appropriate course of action.

User interface changes

None

API changes

This would actually return the API to what it was in 8.4.x, so I consider the current state an api break.

Data model changes

N/A