fix: prevent possible mutex deadlock when using chained sessions
fix: prevent possible mutex deadlock when using chained sessions

When periodically iterating over sessions to see if they need to be expired,
the `memorySessionStore.deleteExpired()` method of the IRMA server locks the
session store mutex, and while that is locked it additionally locks each
session mutex when handling it. If a session is currently being handled by an
endpoint which also locks the session mutex, `deleteExpired()` therefore has to
wait for the handler to finish dealing with the session. However, when that
session attempts to starts a new session (as part of a session chain), it tries
to lock the session store mutex again, which was already locked: a deadlock.

We solve this by making `deleteExired()` not request a session lock while the
entire store is also locked: the store and session locking are now done
sequentially. That way, even when a session is locked by an endpoint in the
loop over the sessions in `deleteExpired()`, that session is free to write new
sessions to the session store.

credentials/irmago