feat: delete unconfirmed users docs

Author: pajgo

doc/rfcs/inactive_users_cleanup.md

@@ -0,0 +1,45 @@
+# Inactive user cleanup
+When user registration finishes and users not passing "activation", corresponding DB record stays for ttl.
+But all metadata/alias/email records stay forever.
+
+1. Add additional Redis HASH and ZSET handling inactive users list.
+2. Change registration action:
+    - remove ttl assignment from from `USER_DATA` key
+    - call inactive list append process `addInactiveUser` 
+3. Change activation action:
+    - add inactive list cleanup `deleteInactiveUser`
+4. Add interval task.
+5. Add config parameter
+6. Move 'delete user' transaction function into separate file from `actions/remove.js` to `utils/removeUser.js`
+
+## Config changes
+Added new `deleteInactiveAccountsInterval` seconds to run cleaner task.
+
+## Constants
+New constants `USERS_ACTIVATE` - ZSET handling userId regtime, `USERS_ACTIVATE_AUDIENCE` - userId to audience binding
+
+## utils/inactiveUsers.js
+Handles all logic, including task creator, and database actions for InactiveUsersList
+
+### addInactiveUser(id, audience)
+Adds corresponding id record into `USERS_ACTIVATE` with score eq current time. Sets `USERS_ACTIVATE_AUDIENCE` hash to track audieces provided in registration process
+
+### deleteInactiveUser(id)
+Removes id dependent data from `USERS_ACTIVATE`, `USERS_ACTIVATE_AUDIENCE`
+
+### cleanInactiveUsers()
+Gets outdated users from `USERS_ACTIVATE` and deletes all user data from database(same as `@ms-users-api.remove`)
+
+
+#### Possible variant
+- Create additional set with id's of inactive users (`users-activate`).
+  * Change activation process: remove successfully activated user id from `users-activate`.
+  * Change registration process: insert inactive user id into `users-activate`.
+- Add repeating task with interval `config.incativeCleanupInterval`.
+  * Sets `dlock` for cleanup operation
+  * Gets list from `user-activate`
+  * Delete all corresponding data from DB for this user id's:
+    all keys `{id}!metadata!{audience}`, and keys from hashes: `USERS_USERNAME_TO_ID`,`USERS_ALIAS_TO_ID`.
+  
+    _NOTE_:
+    User already can be assigned to some organization. So we'll check organisation members key (`redisKey(organizationId, ORGANIZATIONS_MEMBERS)`), organisation member key (`redisKey(organizationId, ORGANIZATIONS_MEMBERS, member.email)`) and redisKey(member.email, USERS_ORGANIZATIONS);