AsyncmongoSession class, used to manage persistence across multiple requests. Uses
a mongodb backend and Cookies. This library is designed for use with
Tornado.

Built on top of asyncmongo by bit.ly - https://github.com/bitly/asyncmongo
The decorator is written to be completely asynchronous and not block.

There are also some built in security features for the session. Only a token
is stored as a cookie, all data is stored in MongoDB. The token rotates
on a schedule you can define, the default is a token is valid for 5
seconds, with the 3 most recent tokens being considered valid. This 
helps lessen the risks associated with session fixation for non-ssl
connections. Because of this the library will be more write heavy than
standard session implementations.

The session is added as session property to your request handler, ie:
self.session. It can be manipulated as your would any dictionary object.

Included with the library is a settings file, configured for default
permissions. Some of the more advanced tuning you can do is with token
expiration. In order to create some additional security for sessions used
in a non-ssl environment, the token stored in the browser rotates. If you
are using ssl, or more interested in performance than security you can set
SESSION_TOKEN_TTL to an extremely high number to avoid writes.

Note: In an effort increate performance, all writes are delayed until after the
request method has completed. 

Example:
    @tornado.web.asynchronous
    @asyncmongosession
    def get(self):
        if self.session.has_key("test"):
            self.session["test"] +=  1
        else:
            self.session["test"] = 0
        self.render("index.html", session=self.session)

IMPORTANT: If using the asynchronous wrapper from Tornado you must wrap
           the asyncmongosession with it, not the other way around. Otherwise
           it will error and not render because the request finish method
           will be called multiple times.

TODO: Support signed cookie data as session data. In instances where the
session data doesn't need to be protected, such as anonymous users, it would
be beneficial to not have any read/write processes happening to the database.