feat: delete unconfirmed users lua doc updates

Author: pajgo

doc/rfcs/inactive_users_cleanup.md

@@ -9,8 +9,7 @@ In order to provide generally better data handling and clean database structure,
   - `inactive-users`
   Redis database sorted set key. Bound to `USER_ACTIVATE` constant.
   Record contains `userId` as value and `timestamp` as score. 
-  - `user-audience`
-  Redis database hash key. Bound to `USERS_AUDIENCE` constant. Stores `userId` to `audience[string]` mapping, contains any audiences used in user's metadata.
+  - `user-audience` [Described here](user_audience_tracking.md)
   - `deleteInactivated` Redis script, handling all cleanup logic
 
 
@@ -57,7 +56,7 @@ When script started:
  11. Key prefix from `THROTTLE_PREFIX` constant = `local kThrottlePrefix`
 
 ### Passed arguments(next `ARG.$ind` used):
- 1. UserAlias field name from user data `USERs_ALIAS_FIELD`
+ 1. UserAlias field name from user data `USERS_ALIAS_FIELD`
  2. UserName field name from data `USERS_USERNAME_FIELD` 
  3. JSON string based on `SSO_PROVIDERS`
  4. JSON string based on `THROTTLE_ACTIONS`
@@ -93,3 +92,11 @@ When script started:
     * forms Throttle `key` names from userId, `THROTTLE_PREFIX`(`KEY.11`)
     * deletes throttle `key`
 
+
+## UPD
+Script has lots of dependent keys and templates. To lower the amount of passed data and avoid some computations we can try to
+generate script on the fly from `template`, as it working in current `utils/updateMetadata` function when updating data with inline scripts.
+General script behavior stays unchanged, but the amount of `json.decode`, `KEYS[]` and `ARGS[]` going to be smaller.
+
+To avoid on the fly generation, the `mfleet.plugin:connect:$redisType` event could be used. When service connects to Redis database,
+script will be generated from the template and registered in `ioredis`.

doc/rfcs/update_metadata_lua.md

@@ -0,0 +1,77 @@
+# User metadata update rework
+## Overview and Motivation
+`ms-users` service uses Redis pipeline based javascript script for updating user metadata records.
+For audience tracking features, there were some logic changes in `utils/updateMetadata.js`, but this brought
+some problems with parallel update requests: Some changes to the user's audience list could be lost.
+It's possible to use `dlock` semaphores to block parallel updates: https://github.com/AVVS/distributed-callback-queue#semaphore, but
+a better solution is to use Redis LUA script, this guarantees that data is updated and all audiences stay in place.
+
+## utils/updateMetadata.js
+Almost all logic presented in this file will be removed and ported into LUA Script.
+This Function will check the consistency of the provided `opts`. If `opts.metadata` and `opts.audiences` are objects, 
+they will be transformed to array. Count of meta operations and audiences checked to equal each other.
+
+After commands execution result returned from the script, decoded from JSON string, all command results that having length == 1
+converted from an array to value from array[0].
+ 
+## script/updateMetadata.lua
+Script repeats all logic including custom scripts.
+### Script parameters:
+1. KEYS[1] - "{ms-users}{userId}!metadata!{audience}"-for proper cluster node handling, and used as metadata template
+2. KEYS[2] - Audiences hashset/keyTemplate [Described here](user_audience_tracking.md)
+2. ARGV[1] UserId
+3. ARGV[2] JSON encoded opts parameter opts.{script, metadata, audiences}
+
+### if Scripts provided
+All scripts evaluated before any execution. This protects us from inconsistent data changes.
+
+### Audience list update
+For proper audience list handling, script get's current list of user's audiences from hset `KEYS[1].userid`, unions them with
+`opts.audiences` and generates full list metadata keys. Iterates over them, to form list of curent user audiences,
+and saves data back into HSET `KEYS[1].userid`.
+
+### Depending on metadata or script set:
+If `opt.metadata` set:
+ * Script starts iterating audiences.
+ * On each audience, creates metadata key from provided template
+ * Iterates over provided in `opt.metadata` operations, based on index of `opts.audiences`. 
+    ```javascript
+     const opts = {
+       audiences: ['first', 'second'],
+       metadata: [{
+         // first audience commands,
+       }, {
+         // second audience commands
+       }] 
+     }
+    ```
+   Commands executed in order: `audiences[0]` => `metadata[0]`,`audiences[1]` => `metadata[1]`, 
+
+If `opt.script` set:
+ * Script starts iterating audiences and creates metadata keys from provided template
+ * Iterates over `opt.script`:
+    * EVAL's script from `script.lua` and executes with params generated from: metadata keys(generated in previous step)
+     and passed `script.argv` 
+    * If script evaluation fails, script returns redis.error witch description.
+
+When operations/scripts processed, the script forms json object like
+```javascript
+const metaResponse = [
+  //forEach audience
+  {
+    '$incr': {
+      field: 'result', // result returned from HINCRBY command
+    },
+    '$remove': intCount, // count of deleted fields
+    '$set': "OK", // or cmd hset result.
+  }
+];
+
+const scriptResponse = {
+  'scriptName': [
+    // values returned from script
+  ]
+};
+```
+and returns as encoded json string.
+

doc/rfcs/user_audience_tracking.md

@@ -0,0 +1,17 @@
+# User's Audience tracking
+## Overview and Motivation
+At present time, the user's assigned audiences not tracking. When you need to get all available metadata assigned,
+you must have hardcoded or predefined list of audiences.
+
+## Audience tracking(single hashset) -- OUTDATED
+To store user audiences used in metadata, add Redis database hash key. Bound to `USERS_AUDIENCE` constant(eg: `{ms-users}user-audiences`).
+Stores `userId` to `audience[string]` mapping, contains any audiences used in user's metadata.
+Data in this key stored as JSON encoded array.
+This saves us from polluting Database keysSpace.
+
+## Audience tracking(multiple sets)
+Audiences stored in sets formed from `USERS_AUDIENCE` constant and `userId`(eg: `{ms-users}10110110111!audiences`). 
+This option saves us from encoding and decoding JSON strings, but producing some KeySpace pollution,
+because each user record will have an additional key with dependent data.
+Brings easier navigation and atomic updates(#IHOPE).
+