Feature/fix session

## Background

We have two separate features; authentication and somehow storing state. At first inspection these aren't related in any way; we'll just throw the state in a global dictionary and be done with it. But when you start thinking about how to load-balance these servers and still have the possibility to maintain per-user state, that global dictionary seems less and less impressive.

## Solving the authentication problem

The authentication problem can be split into two separate parts; the problem of establishing the identity of the user and what's often called the 'session cookie' for that user, which uniquely identifies the user across web requests.

We won't care about the identity problem; that's up to a middleware (when the OWIN branch is done) or to the application programmer.

As for the session cookie we need these properties:

 - [ ] The session cookie should be tamper proof; when a tampered session cookie (i.e. user id, user role, or expiry date) is sent to the web server, it should be rejected.
 - [ ] The session id should not (be likely) collide with other users' session ids.
 - [ ] The session id should be opaque
 - [ ] It should not be easy to steal session cookies through XSS attacks
 - [ ] It should not be easy to append data and modify the contents

## Solving the Stateless Web Server problem

When writing load-balanced and stateless web apps, you need to take care not to save any session data in a stateful store which has not *strictly serializable* semantics from multiple nodes, or you'll end up with race conditions, logic errors or the impossibility to scale horizontally.

Properties:

 - [ ] constraint: We can't save in-memory state beyond the request, because then we need to synchronise it across nodes
 - [ ] constraint: The state cookie should be as small as possible; we have 4 KiB to play with, approximately. As such, it can be a good idea to compress the data.
 - [ ] operations: If we store too much data in there, the framework should SHOUT LOUDLY at the programmer (with appropriate logging)
 - [ ] secrecy: The client must not be able to read the contents of the cookie
 - [ ] authenticity: The client must not be able to modify the contents of the cookie and have it accepted
 - [ ] performance: Given the above cryptographic properties, we just want to perform the heavy lifting once

## Solutions

If we implement an abstraction, a cryptographically secure 'secretbox' which you can put things in with a key, and have it automatically compress the plaintext and then AES256-encrypt + HMACSHA256-sign the encrypted contents we can give this opaque cipher text back as a cookie to the user, and be sure of ticking the 'authenticity' and 'secrecy' properties and the size constraint, above.

We can use the same 'secretbox' for storing the expiry date and session id for the user; as a generic 'auth' cookie. We could also store the session id in plaintext and send with it, a HMACSHA256 signature with the server's key, but then we'd be repeating part of the 'securebox' operations, which can lead to bugs and duplicated code; for no real gain except miniscule performance gains.

For the state, we can save the state in an appropriately serialized format in the same 'securebox' in the cookie and deserialize it without fear or user input/manipulation at the server.

This means we can make it all stateless and secure.