Rework internal session handling and revive session API

[kevinbader]

Maintaining connection state is just part of the story - RIG is also about keeping track of who is online, that is, users and their devices/frontends/connections.

Terminology

• A session is identified by the JWT's ID claim (jti). Consequently, connections not associated with a JWT do not belong to any session.
• All connections a user creates with a single JWT (same jti) belong to the same session. Likewise, a user using multiple JWTs (different jti) can create connections that belong to different sessions. RIG has no notion of user, but instead handles sessions only.

Note: The Session module introduced by #217 is specific to the longpolling feature and it's meaning is not related to what is described here.

Implementation details

• One session manager per node
• Conn procs send heartbeat to their local manager
• Heartbeats contains remote socket and decoded JWTs, if available
• Session managers adds heartbeat info to DeltaCrdt.AWLWWMap
• Session manager join pg2 group and periodically sets up delta_crdt neighbors using that group

Note: If this works well, we should probably follow up with using the same technique for filter supervisors - currently, conn procs periodically refresh subscriptions with all filter supervisors, but it probably suffices to tell only the local one and let delta_crdt take care of state dissemination.

The Session Manager

• receives blacklist requests
• checks jwt expiration
• sends connection termination messages
• publishes “user/device went online (+jwt +nConnections)” and “user/device went offline (+jwt +reason)” events to kafka
• provides the list of online users/connections to :rig_api

Session API

• How many connections are associated to a session?

Possible enhancements to the Session API a.k.a. open issues

• Is user x online? <-- to answer this, we'd need a relation between JWT IDs and user IDs. Perhaps provide an endpoint to query for sessions that have a certain property set in their associated JWT?
• Who is online? <-- same thing here: easy to do for sessions, but we'd have to use configuration or a query parameter to extract the user ID from the associated JWTs.
• Also: Do we need to find out about the online state of users with certain properties?

[Azer0s]

This feature-set can be further described with the following user stories:

Story 1

Alice has a subscription for a service x. Alice has a problem with said service and wants to create a ticket on the service's customer support page. An employee of the customer support department of service x sees that Alice just created a ticket and, furthermore, sees that Alice is currently online.

Story 1.1

[..] The employee can now react and send out a co-worker to get in touch with Alice.

Story 1.2

[..] The employee also sees that Alice's device's locale is set to "en-US" and specifically asks for an english-speaking co-worker to get in touch with Alice

Story 1.3

[..] The employee also sees that Alice's device's locale is set to "en-US" and she is located in the US and sends out an english-speaking co-worker who is familiar with service's x products in the US to get in touch with Alice.

Story 2

Bob is an employee at service x. Bob want's to know how many people are online in certain locations/timezones, what language their devices are set to etc. Bob uses the GraphQL metadata API of RIG to get to informations.

Story 3

John ordered an item on service x. The item is currently in the process of being shipped and will be at Johns place of residency the next day. The backend is about to notify John about this.

Story 3.1

John is currently online, this is picked up by RIG, thus John gets a browser notification regarding the item he ordered.

Story 3.2

John is currently offline, this is picked up by RIG, thus John gets an email regarding the item he ordered.