Session storage

[gsproston-scottlogic]

Set up session storage when we go to production.

If using connect-redis for storage, this requires resave to be false and recommends saveUnitialized to be false in the session.

Update - 25/01/2024

There is the question of whether this is genuinely needed. Does game state really need to persist?

• If someone has beaten the levels before, they should know how to do so again.
• A session will stay active for as long as the user is interacting with the server, plus for a period of inactivity (currently 4hrs in prod). This should be fine for a typical session, even if the user leaves for a break and returns a while later.
• The longer we persist sessions, the more storage we will be using, and the higher the costs.

Currently, sessions are stored in memory. We have a single container, because

• AWS infrastructure is robust so we don't anticipate unexpected server restarts;
• we don't anticipate high traffic needing to be load-balanced across multiple containers.

Therefore all sessions will be stored in memory on the same container, which feels easily good enough for now - until it isn't, at which point we could revisit this issue.

[chriswilty]

We would want to use ElastiCache with Redis, as Memcached does not offer redundancy/replication. They appear to be the same price anyway.