Status of session code

[Cantor, Scott]

Is that it's not really close to stable yet, so I wouldn't waste much time
reviewing my check-ins right now.

It's starting to solidify but until I write the code to handle mutating
data in the session, the storage part will be liable to ripple changes
around the rest of the code.

I do have one design choice to highlight, which is that I'm favoring an
implementation that doesn't try and share a user's session object across
transactions/requests in the IdP, even within a single node. It's
basically handing out the IdPSession object on a per-request basis and the
only shared state across requests is in the storage layer (where I have
versioning support). A consequence is that technically you can have
simultaneous requests active on the same session that will not necessarily
see each other's changes while running, but I don't see that as a bad
trade-off for cleaner code with less complexity. There's also some
overhead for moving the data in and out of storage (or in memory between
serialized and object form), but I don't think it's worth worrying about
until we can test the performance.

The SP actually doesn't do this, it shares session objects across
requests, but I think that's warranted by the fact that an SP has to
handle much more of a barrage of requests against the same session with
high performance. It also makes the code horrendous, so I know what the
cost of doing that is.

*If* we wanted to build a non-replicated SessionManager that was suitable
for in-memory use on one server, I wouldn't do it with the code I'm
writing, it would be a separate implementation to manage the locking and
so forth needed for that to work. And that would be much less complexity
than trying to manage that plus implement cross-node storage at the same
time.

But my expectation is that the common options are going to be for a
storage-based model or a client-side model for real deployments.

-- Scott