LOC-23: Shorter Session IDs

Currently, when a session ID is generated it's 1024 bits/128 octets.

This is then prefixed with the room name, with a hyphen as a delimiter:

[room name]-[session ID]

So, even with a one character room name, that's 130 bytes that must be sent with every request. Those 130 bytes must then be compared to the 130 bytes stored in the database for that user.

The session key currently consists of uppercase ASCII chars and numbers, so the keyspace is 128^36.

The length was chosen arbitarily whilst implementing, and the character set is the same as that used for generating E2E encryption passphrases (makes more sense there as it's easier to copy across).

However, a user never needs to manually enter a session key, so lowercase chars (and even some special characters) could be mixed in. This would allow us to increase the keyspace despite shortening the key length (and lowering payload size as a result).

If we simply add lowercase chars, the keyspace for different lengths would be

- 32^62 = 2.0859248397665138e+93
- 48^62 = 1.7256658998786433e+104
- 56^62 = 2.4415053168670305e+108
- 64^62 = 9.619630419041621e+111

So despite shortening the key length by 75% (if we go with 32 chars) the potential keyspace is still increased considerably.

Session keys are not used for encryption in any way, and only last for as long as a user is in a room. That does need to be balanced against the risk of an attacker trying to factor a key to steal a user's session though, so we should probably go with one of the slightly longer options. 48 octets seems like a good balance