chat groups: establish connection between host and invitee members (#77)

* create group after invitation

* add group invitation to db, show sent and received group invitations

* test creating group and sending invitation

* establish group connections (WIP)

* connect user to the inviter, notification, member classification

src/Simplex/Chat/protocol.md

@@ -97,3 +97,63 @@ A -> group: `MSG: N x.grp.mem.ok G_MEM_ID_B`
 #### Send group message
 
 `MSG: N x.msg.new G_MEM_ROLE,<invitation> x.json:NNN <group_profile>`
+
+#### Group member statuses
+
+1. Me
+  - invited
+  - accepted
+  - connected to member who invited me
+  - announced to group
+    - x.grp.mem.new to group
+  - confirmed as connected to group
+    - this happens once member who invited me sends x.grp.mem.ok to group
+1. Member that I invited:
+  - invited
+  - accepted
+  - connected to me
+  - announced to group
+    - this happens after x.grp.mem.new but before introductions are sent.
+    This message is used to determine which members should be additionally introduced if they were announced before (or in "parallel").
+  - confirmed as connected to group
+2. Member who invited me
+  - invited_me
+  - connected to me
+    - I won't know whether this member was announced or confirmed to group - with the correctly functioning clients it must have happened.
+3. Prior member introduced to me after I joined (x.grp.mem.intro)
+  - introduced
+  - sent invitation
+  - connected
+  - connected directly (or confirmed existing contact)
+4. Member I was introduced to after that member joined (via x.grp.mem.fwd)
+  - announced via x.grp.mem.new
+  - received invitation
+  - connected
+  - connected directly (or confirmed existing contact)
+
+#### Introductions
+
+1. Introductions I sent to members I invited
+  - the time of joining is determined by the time of creating the connection and sending the x.grp.mem.new message to the group.
+  - introductions of the members who were connected before the new member should be sent - how to determine which members were connected before?
+    - use time stamp of creating connection, possibly in the member record - not very reliable, as time can change.
+    - use record ID - requires changing the schema, as currently members are added as invited, not as connected. So possibly invited members should be tracked in a separate table, and all members should still be tracked together to ensure that memberId is unique.
+    - record ID is also not 100% sufficient, as there can be forks in message history and I may need to intro the member I invited to the member that was announced after my member in my chronology, but in another graph branch.
+    - some other mechanism that allows to establish who should be connected to whom and whether I should introduce or another member (in case of forks - although maybe we both can introduce and eventually two group connections will be created between these members and they would just ignore the first one - although in cases of multiple branches in the graph it can be N connections).
+    - introductions/member connection statuses:
+      - created introduction
+      - sent to the member I invited
+      - received the invitation from the member I invited
+      - forwarded this invitation to previously connected member
+      - received confirmation from member I invited
+      - received confirmation from member I forwarded to
+      - completed introduction and recorded that these members are now fully connected to each other
+2. Introductions I received from the member who invited me
+  - if somebody else sends such introduction - this is an error (can be logged or ignored)
+  - duplicate memberId is an error (e.g. it is a member that was announced in the group broadcast - I should be introduced to this member, and not the other way around? Although it can happen in case of fork and maybe I should establish the connection anyway).
+  - member connection status in this case is just a member status from part 3, so maybe no need to track invitations separately and just put SMPQueueInfo on member record.
+3. Invitation forwarded to me by any prior member
+  - any admin/owner can add members, so they can forward their queue invitations - I should just check forwarding member permission
+  - duplicate memberId is an error
+  - unannounced memberId is an error - I should have seen member announcement prior to receiving this forwarded invitation. Fork would not happen here as it is the same member that announces and forwards the invitation, so they should be in order.
+  - member connection status in this case is just a member status from part 4, so maybe no need to track invitations separately and just put SMPQueueInfo on member record.