Rework deletion of temporary users to make the delay between their last activity and the deletion independent of existing sessions

[zenovich]

In #1166 we introduced the delay before deletion of temporary users, but the expiration time of temporary users was determined by the expiration time of their most recent sessions. This approach has two disadvantages:

1. If a temporary user doesn't have sessions at all, it is removed by the delete-temp-users command immediately.
2. If we decide not to keep expired sessions in the DB, we will not be able to determine the expiration time of a temporary users anymore.

For now, the delete-temp-users command seems to be able to work fine anyway, as

1. we always create a new session for each new temporary user, and
2. we do not allow users to log out (and destroy the session), and
3. we keep 10 most recent sessions when we delete old sessions.

Anyway, the situation may change in the future so we need to find a better solution.
The possible solutions could be:

1. Use the latest_login_at field to determine the expiration time of temporary user. For now, we do not update this field on token refreshing, so it doesn't contain the needed timestamp currently. We could update it on each token refreshing, but that would contradict the field name. Probably, we could create another field (latest_access_token_created_at for instance) and update it on every creation of an access token for a user.
2. Use the latest_activity_at field. For now this field is only updated in itemGetHintToken, itemGetAnswerToken, accessTokenCreate (but not for temporary users), userDataRefresh, itemTaskTokenGenerate, so it doesn't contain the needed timestamp currently too. We could update this field every time an API endpoint is called for a user (in UserMiddleware for services requiring authentication and directly in other services). This way, we would be able to rely on the latest_activity_at field for determining the expiration time.

So, we need to choose the appropriate solution before reworking the implementation.

[smadbe]

I would prefer not creating a new attribute for that as there are already different one that we do not really use.
I am afraid that updating latest_activity_at on every single call may be expensive (we will quickly be >1k updates/sec, with many of the same user) and it is not helpful to have milliseconds precision on that.

So either:

• we consider that latest_activity_at should have, let's say 1min accuracy, and we update it only if it is older than 1min
• we define what an activity is in such a case, and it could add any type of progress of the platform so including the attempt/result creation on an item. Of course token access refresh for temp if possible should be added to prevent removing a token which is still active... or at least we should ensure that we do not delete users who still have valid sessions.