Add sqlite for history persistence

[felix]

This adds a persistence store for history alongside MySQL (and any future options).

For many smaller installations the need to run MySQL can be too much, but at the same time history persistence is desirable. The use of projects like litestream mean the Sqlite database can still be backed up and persist between restarts and server instances. Obviously not suitable for multiple instances of ergo.

This adds in-process Sqlite for history storage:

• Update the config to allow selection of storage type (none, sqlite, mysql)
• Update defaultconfig to reflect above changes
• Use modernc.org's Sqlite to avoid CGO
• Use zombiezen's Sqlite driver (not a database/sql driver) which allows savepoints for transactions
• Takes a lot of logic from the MySQL version

Currently a WIP while I:

• Run tests
• Get feedback

[slingamn]

Thanks for looking at this! You may want to take a look at #2322 if you haven't already (it has some patterns that are relevant, e.g. handling database-specific configuration and allowing databases to be compiled out).

How is performance? I tried a sqlite conversion and it ran very slowly, although it may have been an issue with my virtualized testing environment.

[felix]

I did briefly look at that PR but I imagine there is going to be a lot of shared config between any history store. Also, I think it makes sense to have an enum/selector for the type (sqlite/mysql/pgsql) so there is no possibility of having multiple databases 'enabled'.

As for performance, tbh I have not had much opportunity to test it yet. Sqlite can handle large datasets and if retention is set well it should be fine. But as I said, have not put it through its paces yet.

[NyaaaWhatsUpDoc]

enabling WAL with multiple concurrent connections (only from a single process ofc) and a busy timeout set performs really well from our experiences on gotosocial. we have users running 20+GB databases with 20mil row tables on tiny VPSes just fine. our users experiencing performance issues are usually using our postgres driver.

personally we use github.com/ncruces/go-sqlite3, which embeds a WASM sqlite3 binary and uses a WASM runtime which AoT compiles the web assembly to native assembly for the running platform. but we have also had good experiences with modernc.org/sqlite (though using a fork with a concurrency fix since upstream hasn't been able to repeat or fix a concurrency issue we've seen with their driver in gotosocial).

[felix]

Seems it is not required any more.

[slingamn]

Thanks for the contribution! It was helpful to me when evaluating performance issues and different drivers.

I thought that keeping the normal database/sql interface (as opposed to the zombiezen API which is closer to the sqlite C API) would be more maintainable, because it's at closer parity with the mysql and postgres implementations.