Add conversation API, introduce Exchange history

[calyptobai]

In this PR, we add an sqlite database for storing conversation history. We also add a few endpoints for managing this history, namely listing, deleting, and retrieving conversations.

The ResponseState struct has been simplified and refactored into the idea of an Exchange. Exchanges are stored directly in the corresponding Conversation for retrieval at a later date.

Using sqlx with the database

To create new queries or modify existing ones, we can use sqlx. You'll need to cargo install sqlx-cli first, then these commands can be run from within server/bleep:

• sqlx database reset --database-url=sqlite://bleep.db: This will set up the database from scratch, deleting an old database if it exists
• cargo sqlx prepare --database-url=sqlite://bleep.db: This will update the sqlx-data.json file, which is nominally used to build the app without requiring a database instance.

[oppiliappan]

works great, we should merge this in.

couple of questions (just want to discuss these, no changes required here):

• we introduce a new data_dir, is there a reason we need a separation between the index_dir and the data_dir?
• a conversation id is unique by means of (user_id, thread_id), can we make that the primary key instead?

[calyptobai]

@nerdypepper

we introduce a new data_dir, is there a reason we need a separation between the index_dir and the data_dir?

The index_dir is a cache dir stored in a location like ~/.cache; it's not persistent so it's not suitable for storing the DB.

a conversation id is unique by means of (user_id, thread_id), can we make that the primary key instead?

Storing an integer ID allows us to reference these rows in the future in a much easier way using a single INTEGER. This way if we add new tables, we don't have to store composite foreign keys, which tend to be very bulky to work with. We could add an index over the composite key, although the table size will likely always be small making this totally unnecessary.