Feat(persistent-session): Implementation

[JumpLink]

• Removed valtio and it's dependency
• Splitted session data into data which can be persistent and data which can not be persistent
• The data in the session (that can be persistent) is persistent now by using Deno KV (A Deno build-in Key/Value Database which can just be use without a new dependency).
• Removed the shortSlug workaround and use the Callout id instead, this makes sense because we have previously stored the shortSlugs in memory and therefore do not need to make them persistent.

Note

The database file is stored in the following directory: telegram-bot/data which should already be persistent in our Docker Compose stacks with has the Telegram Bot Service

Checklist

After the bot has restated:

• The previous session is restored
• When callouts are listed before, a callout can still be selected
• If the user has just answered a callout, they can continue with their last answer.

What is missing?

In order for the user to continue answering a callout with his last answer, we need to store the following data in the session:

• The last answers given
• The CalloutID
• Possibly more?

With this data, we then have to jump back to the callout responses and skip the callout forms for the ones that have already been answered.

This data could be stored in the session inside the CommunicationService.sendAndReceiveAll method. This method is used to send the callout forms in sequence and to collect the responses / answers. The problem here is that I am currently not only storing pure data in the object of type RenderResponse, but also, for example, the keyboard, which is an instance of a class, and instances of a class cannot be persisted. So something would have to be restructured here what I'm not finished yet.

However, I think that the PR can still be merged and the restoration of the callout answering can still be implemented afterwards. In this way, the persistent session could still be used for other features.